# HDS Compliance Matrix — full text Generated 2026-09-11 from https://github.com/healthdatasafe/compliance-matrix Summary and the rules for computing an implementer's answer: https://compliance.datasafe.dev/llms.txt NOT LEGAL ADVICE. Engineering and operational guidance; confirm obligations with counsel. This matrix covers the HDS vault product: individuals hold their own accounts, data enters only with their explicit consent, and they decide who may access it. HDS is the controller of the vault, is nobody's Art.28 processor, and holds no HIPAA role in it. Each requirement is answered across three layers: the open-pryv.io PLATFORM (inherited), HDS as operator, and the IMPLEMENTER building on it. An hds_posture block per framework states how HDS ITSELF stands, which is a different axis from what HDS carries for an implementer. ## Report back what this told you If you are using this file to answer a real question for a real project, open an issue on the board below. It is read as part of HDS's regular review, so a report there reaches the people who maintain this matrix. Nothing else does. https://github.com/healthdatasafe/compliance-matrix/issues Pick the label that fits: documentation it matched what the project actually had to do bug something here is wrong, missing or misleading question you could not work out an answer from this file Put in the body: what is being built, the answer you computed (which frameworks applied, which persona, what obligations you listed), and what was wrong or unclear. A report without those inputs cannot be acted on. If you are an AI agent: ask the person you are working for before opening an issue, and put nothing confidential in it. The board is public. Where what is being built cannot be described publicly, write instead to contact@healthdatasafe.org TEMPLATE baa: Business Associate Agreement (template) — signer: covered-entity, counterparty: business-associate. Template BAA for a Covered Entity (or upstream Business Associate) to sign with ITS OWN business associates. NOT for use with HDS: in the vault product HDS holds data for the individual, who grants access directly, so it maintains nothing on a customer's behalf and is nobody's business associate there. TEMPLATE dpa: Data Processing Agreement (template) — signer: controller, counterparty: processor. Template Data Processing Agreement (GDPR Art.28 / Swiss nLPD) for an organisation building on HDS to sign with ITS OWN processors, for the copy of personal data it holds on its own systems. NOT for use with HDS: for the vault product HDS is the controller of the individual's vault and cannot be anyone's Art.28 processor. TEMPLATE subcontractor: Subcontractor Agreement (HIPAA flow-down, template) — signer: business-associate, counterparty: subcontractor. Template back-to-back agreement by which a Business Associate flows its HIPAA obligations down to a subcontractor that handles ePHI on its behalf. TEMPLATE subprocessor: Subprocessor Disclosure & Assurance (template) — signer: business-associate, counterparty: subcontractor. Template for disclosing the subprocessors used to handle ePHI and recording the assurances obtained from each — the operational companion to the subcontractor agreement. # General Data Protection Regulation (gdpr) regulation · EU + EEA (extraterritorial via Art. 3) · Regulation (EU) 2016/679 (consolidated) · regions: ch, us Official text: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02016R0679-20160504 HDS's own position on GDPR: - vault: HDS is 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. External assurance: self-assessed. No supervisory-authority certification under Art.42, no independent audit and no readiness review has been performed against this scope. Every claim below is HDS's own assessment of HDS, reviewed internally only. Certificates HDS relies on but does NOT hold: AWS ISO/IEC 27001, 27017 and 27018 (us region hosting layer, obtained 2026-07-28) Evidence: 3 of 47 requirements answered from approved HDS documentation (41 cite internal evidence), as of 2026-09-10. 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. NOTE: 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. Known gaps in HDS's own position: - [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. - [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. (refs: 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. (refs: 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. (refs: 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. (refs: Art.17) - [low] HDS's own DPIA process is drafted internally but is not yet a running procedure with a first executed assessment. (refs: Art.35) ## gdpr Art.1 — Subject matter and objectives Requirement: Rules on the protection of natural persons regarding the processing of their personal data, alongside rules ensuring its free movement. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-1 PRYV PLATFORM: facilitated (mode: awareness) GDPR's purpose is to protect natural persons in how their personal data is processed, while keeping that data freely movable. Pryv is designed for exactly that: your subjects own their data, and technical controls enforce the consent they granted, and the API is open so data can move without lock-in. The per-article rows below describe how each obligation maps to the primitives Pryv gives you. Detail: Protection of natural persons (re: processing of their personal data): - Subject-centric storage, each of your users has dedicated storage; you host but don't commingle subjects. - Technical access control, permissions per stream are enforced at the API surface; processing only happens within the scope the subject granted. - Versioned consent record, access + clientData + consent events form a tamper-evident chain of what was authorised, when, with which contract text. - Accountability by construction, audit rows reference the specific access version used at processing time. Free movement of personal data: - Open HTTP API, events / streams / accesses consumable without vendor SDKs. - Canonical event-type schemas, structured JSON with stable class/format semantics; portable across deployments. - Cross-platform sharing, independent Pryv operators can exchange data + consent without shared trust, shared user namespace, or federation auth. - No vendor lock-in; you can move data + consent contracts between operators using the same primitives an end-user would use to read them. A Pryv deployment cannot, on its own, make you GDPR-compliant, but it gives you the technical substrate on which the per-article obligations below can be discharged. HDS: documented (effort saved: low) As an operator running the open-pryv.io platform, HDS supplies the technical substrate on which the per-article obligations below are discharged: per-subject storage isolation, stream-scoped permissions, and an audit chain. HDS-as-platform cannot by itself make a controller compliant; the article-level rows describe the division of effort. Detail: HDS hosts each data subject in dedicated, non-commingled storage and enforces consent technically at the API surface. The controller building on HDS carries the substantive accountability for lawful, fair and transparent processing. The free-movement objective is served by the open API and canonical event-type schemas that avoid vendor lock-in. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Run your own data-protection programme over the HDS substrate; the per-article rows show what HDS carries and what stays with you. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.2 — Material scope Requirement: Applies to processing of personal data by automated means, and to non-automated processing of data forming part of a filing system. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-2 PRYV PLATFORM: facilitated (mode: awareness) Your Pryv deployment is fully inside Article 2's material scope. Every event you store and every API call your apps make is automated processing covered by GDPR. Pryv does not exempt you from any per-article obligation; it gives you the technical primitives that make those obligations addressable (see Art.5+). Branch 2 (non- automated processing inside a "filing system", structured paper records) doesn't surface at the Pryv layer; your own paper records, if any, are outside the software boundary. Detail: GDPR Art.4(6) defines "filing system" as any structured set of personal data accessible by specific criteria, alphabetised customer cards, dated patient folders, indexed application forms. Random unstructured paper or spoken-only data is not in scope. Pryv is fully digital, so branch 1 always applies; branch 2 is moot. If you also keep paper records as part of the same business process, those fall under branch 2 but as a separate process you manage outside Pryv. HDS: documented (effort saved: low) Every event stored on HDS and every API call against it is automated processing within Article 2. HDS does not exempt any deployment from the per-article obligations; non-automated paper records, if any, sit outside the software boundary and remain the controller's concern. Detail: Because HDS is fully digital, the automated-processing branch always applies. Whether a controller also keeps structured paper records (the filing-system branch) is a separate process the controller manages outside the platform. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: always; nature: orientation (not a duty) Confirm your processing is in scope (it generally is) and manage any out-of-band paper records separately. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.3 — Territorial scope Requirement: Applies to processing in the context of an EU establishment, or to processing relating to data subjects in the Union. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-3 PRYV PLATFORM: facilitated (mode: infrastructure) Whether GDPR applies to your Pryv deployment depends on where you're established and where your data subjects are, not on the software. Pryv is self-hosted, so you control data residency directly: the multi- hosting feature lets you choose which jurisdiction each core runs in, and either let end-users pick their hosting at registration or auto-route them by your policy. If any of your subjects are in the EU/EEA, GDPR applies to your deployment in full. Detail: Pryv supports a single logical platform spanning multiple hostings (different countries / cloud regions / on-premise). Two routing policies you can apply: - **End-user choice**: your registration UI presents the available hostings (via `auth.hostings`); user picks. Useful for consumer apps where subjects assert their own residency preference. - **Operator / regulatory routing**: your app auto-routes based on the subject's jurisdiction or contract terms (e.g., EU subjects → EU hosting; French health data → HDS-certified French hosting). The chosen hosting binds the user's data to that core permanently. `system.users.get` exposes the per-user hosting so you can surface it in the app ("your data is stored in "). Note: even with EU-only hosting, if you have a non-EU establishment offering services to EU subjects, Art.3(2) still pulls you into GDPR. HDS: facilitated (effort saved: medium) (mode: infrastructure) HDS offers data residency in Switzerland (Exoscale) and the US (AWS), and the individual chooses the region when they register their vault. The Swiss option keeps EU and EEA subject data under an adequacy regime; the US option is an international transfer (see Art.44-49). Whether the GDPR applies at all is a function of establishment and subject location, not of the platform. Detail: HDS pins each subject's data to the region the individual chose at registration and exposes that region per user, so an organisation can see where a given vault sits rather than assign it. Even with Swiss-only residency, a non-EU establishment offering services to EU subjects is still pulled into the GDPR under Art.3(2), a determination that organisation makes for itself. Evidence: internal:gdpr/policies/international-transfers, internal:hipaa/registers/hosting-provider-attestations IMPLEMENTER [controller] coverage: documented applies_when: always; nature: orientation (not a duty) Work out whether the GDPR reaches your own processing, if you carry out any. Note that the region a vault lives in is chosen by the individual at registration, not by you. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.4 — Definitions Requirement: Defines key terms: personal data, processing, controller, processor, consent, profiling, pseudonymisation and others. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-4 PRYV PLATFORM: facilitated (mode: awareness) Article 4 defines GDPR vocabulary. Pryv's primitives map cleanly to most of these terms, easier for you to point auditors at concrete artefacts rather than abstract concepts. Detail: Approximate mapping of key GDPR terms to Pryv primitives: | GDPR term | Pryv primitive | |---|---| | personal data | `event` content + attachments on a user's account | | data subject | the user (account owner) | | controller | typically you, the implementer | | processor | the Pryv operator (when distinct from you) | | recipient | a counterparty holding an `access` to the data | | third party | another deployment / app accessing via shared/app `access` | | consent | app/shared `access` with `permissions` + `clientData` carrying the contract (see Art.7) | | processing | any API call on `events.*` / `streams.*` / `accesses.*` (audit-recorded) | | filing system | N/A, Pryv is fully automated | | personal data breach | event/audit anomaly + post-mortem (see Art.33) | | pseudonymisation | `accesses.create {randomAlias:true}` (platform-unique routable alias hides the username per access) + system-streams + custom event-type design | | profiling | application-side concern (out for Pryv) | | restriction of processing | scope-down via `accesses.update` (see Art.18) | The controller/processor distinction is contractual; you assign the roles. Pryv lets you record the assignment explicitly in `access.clientData` if you want it traceable. HDS: documented (effort saved: medium) HDS maps GDPR vocabulary onto concrete platform artefacts: personal data is event content, the data subject is the account owner, consent is the granted access plus clientData, processing is any audited API call, and pseudonymisation maps to the platform's alias primitive, accesses.create {randomAlias:true}, which mints a platform-unique routable r-XXXXXXXX alias hiding the username per access, deployed on the HDS cores since 2026-07-28. For the vault, HDS is the controller: it determines the purposes and means of operating it, and data enters only with the individual's explicit consent. An organisation that receives data an individual chose to share is an independent controller of what it then holds. Detail: HDS is nobody's Art.28 processor for this product, and the role assignment is not merely contractual: it acts on the individual's permissions rather than on a controller's documented instructions, which is the test Art.28(3) sets. The mapping of terms to primitives lets an organisation point an auditor at artefacts rather than abstractions. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Work out your own role for each processing activity you carry out. For a vault, HDS is the controller and you are an independent controller of whatever an individual chooses to share with you. IMPLEMENTER [processor] coverage: documented applies_when: always Where you process on behalf of another controller, document your processor role and the instructions you act on. Templates to sign: dpa ## gdpr Art.5 — Principles relating to processing of personal data Requirement: Lawfulness, fairness, transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; accountability. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-5 PRYV PLATFORM: implemented Several Art.5 principles are technically enforced for you by Pryv rather than left to policy: purpose limitation (per-stream permissions), accountability (audit chain to the consent state), accuracy (event versioning). Lawfulness, fairness and transparency stay on your shoulders; Pryv stores the notice/consent text you present but doesn't generate it for you. Detail: Per-principle breakdown, what Pryv does for you, what you do: - Lawfulness, fairness, transparency (§1(a)), DOCUMENTED. You write the notice and present it; Pryv carries the text in `access.clientData` or a `consent/request-cmc` event so the same text is recoverable later. - Purpose limitation (§1(b)), IMPLEMENTED. `permissions` per stream technically restrict reads/writes to the granted scope; an app cannot access streams outside its granted permissions. - Data minimisation (§1(c)), FACILITATED. Permissions + stream design let apps see only what's in their scope; the rest is invisible to them. - Accuracy (§1(d)), FACILITATED + IMPLEMENTER-OWNED. Pryv enforces **structural** accuracy at ingest: every `events.create` and `events.update` validates against the declared event-type's JSON Schema (ajv-draft-04 via `components/utils/src/jsonValidator.ts`), rejecting out-of-shape or out-of-range payloads with HTTP 400. Numerical bounds (`minimum`/`maximum`), string patterns, and length limits are expressible per type, the HDS data-model exemplar declares 28 `minimum`/23 `maximum` constraints across health-data types. The built-in catalogue uses bounds sparingly (operator opts into strictness by extending via `service.eventTypes` URL, Q14 pattern). **Semantic** accuracy, "is this medication right for THIS patient?", is out of scope by design; the implementer's app layer carries the clinical / domain context Pryv intentionally doesn't see. `events.update` rectifies events (Art.16); event versioning + `GET /events/:id?includeHistory=true` preserves the prior value for traceability. Full split in `context/data-accuracy-structural-vs-semantic.md`. - Storage limitation (§1(e)), VOLUNTARILY MISSING + OPERATOR-OWNED at the retention-enforcement layer + CONFIGURABLE at the erasure-mechanics layer. Pryv exposes no TTL / auto-delete / scheduler primitive, automatic retention is the operator's external job, composing `events.get toTime=` + `events.delete` (two-stage) + `streams.delete` + `auth.delete` + the audit log as inactivity oracle. Every retention deletion is captured by the audit log automatically (Q9 audit-by-construction). Engine-dependent backup-tail considerations apply (see Art.17). Full pattern + cron-job recipe + audit-trace treatment + "why not built-in" rationale in `context/data-retention-operator-owned.md`. - Integrity & confidentiality (§1(f)), covered separately at Art.32. - Accountability (§2), IMPLEMENTED. Every API call audited with the access reference + version; access carries the consent state at that version → end-to-end accountability chain you can point auditors at. HDS: facilitated (effort saved: medium) (mode: primitive) Several Art.5 principles are carried technically by the HDS platform: purpose limitation via per-stream permissions, accountability via the audit chain tied to the consent state, structural accuracy via schema-validated writes. Lawfulness, fairness and transparency remain the controller's. Storage limitation (automated retention) is a known gap — HDS exposes no TTL/scheduler primitive. Detail: Purpose limitation and accountability are enforced at the API surface and recorded in the audit log. Accuracy is enforced structurally at ingest (JSON-Schema validation) and traceably on rectification (event versioning); semantic accuracy stays with the controller's app. Data minimisation is facilitated by stream design plus default-deny permissions. Storage limitation has no built-in enforcement: automated retention is operator/controller-owned and must be composed externally. Evidence: internal:gdpr/policies/data-retention, internal:hipaa/policies/minimum-necessary, internal:hipaa/policies/integrity IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy, analytics, secondary-use] Establish lawful basis, notices and a retention schedule; HDS does not set these for you. Automated retention deletion is your job to build. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.6 — Lawfulness of processing Requirement: Processing is lawful only if at least one of six bases applies; further processing for a new purpose needs a compatibility test or a fresh basis. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-6 PRYV PLATFORM: facilitated (mode: storage) You decide which Art.6 basis you're relying on for each processing activity. Pryv doesn't impose or check the basis. You can record your chosen basis in `access.clientData.lawful_basis` so it travels alongside the technical authorization and lives in the audit trail, handy when an auditor asks "under what basis was this access made?". For Art.6(4) further processing (purpose pivot), Pryv exposes four composable patterns + a clear decision rule for when the purpose pivot demands fresh consent vs. an in-place update, see detail. Detail: Recording the basis on the access gives you a durable, versioned artefact tying the basis to the specific processing scope it justifies. Determination of which basis applies remains your responsibility, Pryv neither enforces nor refuses on the basis claim. **§4, further processing (purpose pivot).** Four composable patterns; choose per the compatibility-vs-fresh-consent decision rule below. **Pattern A, Mint a new access for the new purpose.** The cleanest fit when the new purpose is **outside** the original OR is not covered by a fresh override-by-law basis (Art.6(4)(a) compatibility test fails). The subject sees a fresh auth flow; `app-web-auth3` presents the new notice + new purpose explicitly; the new access carries `clientData.purpose: ` + `clientData.lawful_basis: `. Old access keeps operating for its original purpose (or is revoked separately if withdrawn). This pattern is the **mandatory** path when the compatibility test fails, fresh consent is required. **Pattern B, Update existing access** (`accesses.update`). Suitable when the purpose change is narrow / compatible (e.g., scope-down or compatible expansion). The pre-mutation `permissions` + `clientData` snapshot into a history row automatically (see `context/access-versioning.md`), preserving the purpose-history chain end-to-end. The bumped `accessSerial` threads through the audit log so post-pivot rows correctly attribute to the new purpose state. **Pattern C, Separate compatibility-assessment event.** When the operator wants the Art.6(4) 5-factor analysis itself recorded as a first-class artefact, write a `compliance/compatibility-assessments/` event on a dedicated stream (operator-authored format via Q14 custom catalogue) capturing the §6(4)(a)-(e) reasoning + the affected data scope + the decision outcome. The relevant access(es) then reference it via `clientData.compatibility_assessment_event_id`. This pattern composes with A or B (the assessment artefact justifies the pattern choice). **Pattern D, Sub-access derivation from an `app` access** (`createdBy` mechanism, see `context/workforce-access-patterns.md` Pattern 2). When the operator's app holds an `app`-type access with broad scope; it can mint per-purpose **sub-accesses**, each carrying its own narrower `permissions[]` + `clientData.purpose`: and the audit log records each sub-access's id independently, **feeding purpose-driven access matching into the audit trail at query time** (`audit.get` → group by `accessId` → distinct purposes touched). Especially clean when the same app legitimately operates under multiple compatible-purpose facets, each facet gets its own sub-access, so per-purpose disclosure accounting (Art.30 / §164.528) reconstructs from the audit log without operator-side bookkeeping. **Decision rule** (operator-side): 1. New purpose is **inside** the original purpose's scope (a compatible refinement / narrowing) → **Pattern B** update existing access. No fresh consent. Update notice if material. 2. New purpose is **alongside** the original (compatible expansion, same app, multiple facets) → **Pattern D** sub-access mint, OR **Pattern A** new access. No fresh consent required if compatibility test passes; transparency-notice update may be required under Art.13(3). 3. New purpose is **outside** the original AND not covered by a fresh override-by-law basis (Art.6(1)(c)/(d)/(e)) → **Pattern A** mint new access + force fresh consent. The subject's positive opt-in is mandatory under Art.6(4) when compatibility fails. App-web-auth3's grant flow IS the re-prompt mechanism. 4. In **any** case where the 5-factor compatibility analysis was non-trivial → **Pattern C** separate compatibility- assessment event for audit-defensibility. **Re-prompt surface (§4 fallback):** Pryv has no built-in "notice changed → automatically re-prompt subject" workflow. The operator's app layer triggers re-auth by minting a new access (Pattern A), `app-web-auth3` presents the updated notice; the subject's positive consent IS the fresh-basis capture. For revocation of the old access alongside the new mint, `accesses.delete` is the standard path (Q19 / Q28 mechanism family). **clientData convention extension** for §4 purpose pivots: `compatibility_assessment_event_id` + `purpose_change_basis` (`compatible_purpose` / `new_consent` / `new_legal_obligation` / `new_legitimate_interest`) + `previous_purpose` (the pivot record). See `context/client-data-conventions.md`. HDS: facilitated (effort saved: low) (mode: storage) HDS does not impose or check the lawful basis. It provides the means to record the chosen basis on the access clientData so it travels with the technical grant and into the audit trail. Determining which Art.6 basis applies, and assessing any purpose pivot under Art.6(4), is the controller's responsibility. Detail: Recording the basis on the access yields a durable, versioned artefact tying the basis to the scope it justifies. A purpose pivot can be handled by minting a new access (fresh consent) or scoping an existing one, with the version chain preserving the history; the compatibility judgement is the controller's. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [connects, analytics, secondary-use] Determine and document the lawful basis for each processing activity you carry out, and record it in your own Art.30 register. The grant an individual gives you evidences their consent to share; it is not a record of your basis for what you then do. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.7 — Conditions for consent Requirement: Where processing relies on consent, the controller must demonstrate it; the request must be intelligible and the consent withdrawable. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-7 PRYV PLATFORM: implemented The access Pryv mints when your user grants permission IS your durable consent record, versioned permissions + clientData together prove what was authorised, with what text, at what time. Withdrawal is a single API call. For cross-account sharing, the `consent/*` events carry the negotiation state transitions. Both records are immutable per their primitive's semantics. Detail: Demonstrability (§1), `accesses.get ?includeHistory=true` returns the full version chain; each version preserves the `permissions` granted and the `clientData` (which can carry the consent contract text) at that point in time. For cross-account flows, the original `consent/request-cmc` event on the requester's account holds the localised consent text presented. Withdrawal (§3), `accesses.delete` (full revoke) or `accesses.update` with narrower `permissions` (scope-down). Both bump the access serial + snapshot the pre-mutation state. Cross-account: `consent/revoke-cmc` triggers symmetric teardown on both sides via the CMC plugin. Intelligible form (§2): you write the UX (app-web-auth3 template is a starting point). Pryv enforces the technical contract; your UI presents it. Granular consent (§4), different processing purposes can be expressed as separate accesses with different permissions, each independently withdrawable. Second consent path, OAuth2 authorization (§1, §4), where your user authorises a delegated app through Pryv's OAuth2 authorization-code flow (`open-pryv.io/components/oauth2/`, open-pryv.io 2.0.0-rc.8), the granular consent screen presents the referenced offer's per-permission set and lets the user untick individual permissions to downgrade the grant before accepting; the accepted subset (`grantedPermissions`, validated ⊆ the signed offer) is what Pryv mints the app access from (`open-pryv.io/components/oauth2/src/routes/accept.ts`). The durable consent record is the same primitive as everywhere else, a cross-account CMC data-grant access, versioned and revocable; revoking it tears down the app's refresh chain. Demonstrability rests on that data-grant + the signed offer material (the access + its version history), not on a separate event log. HDS: facilitated (effort saved: high) (mode: primitive) HDS exposes the @pryv/cmc consent flow and access-grant primitive: the access minted on grant is a versioned, immutable consent record binding the granted scope to the consent text, and withdrawal is a single API call. The intelligibility of the notice and the consent UX is the controller's editorial responsibility. Detail: Demonstrability rests on the access version chain (permissions plus clientData preserved per version) and, for cross-account flows, the consent/* event sequence carried by the CMC plugin. Withdrawal is a full revoke or a permission scope-down, both versioned and auditable. Granular consent is expressed as separate per-purpose accesses. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Write the consent UX and notice text; HDS preserves and versions the record but does not author the request. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Grant and withdraw consent through the access primitive at any time. ## gdpr Art.9 — Processing of special categories of personal data Requirement: Processing of special-category data (incl. health, genetic and biometric data) is prohibited unless one of the Art.9(2) conditions applies. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-9 PRYV PLATFORM: facilitated (mode: primitive) Pryv is content-agnostic at the platform layer, no `sensitivity:` flag on event-type schemas, no server-side hook that refuses writes to "health" streams without a recorded Art.9(2) basis. **Classification is voluntarily missing at the platform.** But for **vertically-integrated operators** (you run the core AND ship the clients AND design the stream tree AND curate the event-type catalogue, typical for health deployments), Pryv exposes enough composable primitives that you build a strong Art.9 enforcement layer without platform-imposed assumptions. The Art.9(2) condition relied on lives in `access.clientData.special_category_basis` next to the technical grant. Full operator-toolkit treatment + two-deployment-topologies framing in `context/special-categories-operator-facilitated.md`. Detail: Recommended stream-layout pattern for special-category-heavy deployments: - Reserve top-level subtrees per Art.9(1) category (`health/`, `biometrics/`, `genetics/`, `political-opinions/`, etc.). - Mint apps' / counterparties' accesses with explicit `permissions[]` listing the subtree they may touch; default-deny everything else. - Record the Art.9(2) lit-letter in `access.clientData.special_category_basis` ("(a) explicit consent", "(h) preventive / occupational medicine", etc.). - Audit log automatically captures every read / write under the access. **Operator-toolkit composition** (vertically-integrated deployments, operator controls both ends): 1. **Stream-tree design**: operator's client code routes sensitive writes exclusively to reserved subtrees; Pryv enforces the per-stream permission boundary (`AccessLogic`). 2. **clientData.special_category_basis**: Art.9(2) lit-letter recorded on every access touching a sensitive subtree; access-versioning preserves the basis over edits. 3. **Custom event-type catalogue annotations**: operator extends `service.eventTypes` URL with `x-art9-category` / `x-swiss-nlpd-sensitive` / etc. fields the client code reads to gate writes; Pryv passes the annotations through unchanged (Q14 / Q21 pattern). 4. **Custom dataStore (`@pryv/datastore`)**: sensitive subtree owned by a dedicated store with stricter at-rest encryption + access controls (Q16 pattern; `context/audit-archival-via-custom-datastore.md`). 5. **Per-engine isolation**: sensitive tier on a separate PostgreSQL instance / WAL / replicas (storage-engine plugins). 6. **`customExtensions.customAuthStepFn`**: operator-side gate that demands the Art.9(2) basis claim at access-grant time before minting the access. 7. **Audit log**: automatic capture of every read/write under any access; audit-minimality (Q9: no request body) is a feature for sensitive data, not a limitation. 8. **Backup tiering (Q15)**: operator wraps sensitive-tier dumps with stricter encryption + retention than ordinary tiers; `bin/backup.js` is the integration point. The toolkit's reach varies by deployment topology, full strength for vertically-integrated operators, partial for open Pryv platforms hosting third-party apps the operator doesn't author. The two-topology framing is canonical in `context/special-categories-operator-facilitated.md`. Caveat: Pryv's permission model is per-stream, not per-field within an event. If an event mixes ordinary and special-category fields, you must split it or design your event types so the special-category subset is its own event-type. HDS: facilitated (effort saved: medium) (mode: primitive) Health is HDS's primary use-case. The platform is content-agnostic — no server-side sensitivity flag — but as a vertically-integrated operator HDS designs the stream tree and event-type catalogue so special-category data lands in reserved subtrees with tightly scoped, default-deny accesses. The Art.9(2) condition relied on is recorded on the access clientData. The substantive condition determination stays with the controller. Detail: Recommended layout reserves top-level subtrees per Art.9(1) category, mints accesses listing only the subtrees they may touch, and records the Art.9(2) lit-letter on the access. Per-stream (not per-field) permission granularity means events mixing ordinary and special-category fields must be split into distinct event-types. Evidence: internal:gdpr/policies/lawful-basis-and-consent, internal:hipaa/policies/access-control IMPLEMENTER [controller] coverage: documented applies_when: [connects, stores-phi-copy, analytics, secondary-use] Determine the Art.9(2) condition for each special-category activity you carry out, and record the basis. Ask for the narrowest scope you need; the vault's stream layout is HDS's and the individual's, not yours to design. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.8 — Conditions applicable to child's consent in relation to information society services Requirement: Where consent grounds a service offered directly to a child, processing is lawful only at/above the applicable age; below it, a parental holder must consent. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-8 PRYV PLATFORM: facilitated (mode: storage) Pryv neither knows nor validates a subject's age, age + parental-authority verification happens at your app's registration / consent UX. The platform is age-blind by design (verified: default `custom.systemStreams.account` ships only `email`; no `birthDate` / `dateOfBirth` / `minor` field in the catalogue). Once verified, the artefacts you keep travel alongside the access via the `clientData` convention family (see `context/client-data-conventions.md`). Detail: Convention (operator-side editorial discipline; no Pryv enforcement): - `account.clientData.age_verification_method`, free-text or structured record of HOW age was verified (self-declaration / ID upload / parental-attestation / government-eID-flow). Travels with the account; reachable via the system-stream account event. - `clientData.parental_holder_consent_event_id` (singular, single-holder case) or `clientData. parental_holder_consent_event_ids` (array, dual / multi-holder case, divorced parents, jurisdictions requiring both biological parents, foster care, etc.), pointer(s) to the actual `consent/parental-*` event(s) recording the parental consent text + the holder's identity / verification trail. **The `consent/parental-cmc` event format does NOT ship in the built-in `data-types` catalogue.** Operators needing this format author it themselves and publish via `service.eventTypes` URL (the Q14 custom-catalogue extension pattern). HDS-style data-model repos that target paediatric / adolescent use-cases are the natural home for this format. Backlog candidate: if a critical mass of health deployments converges on a common shape, upstream it into `data-types` proper. **Re-verification on age-of-majority transitions**, voluntarily missing at platform layer. Pryv has no cron / scheduler primitive. Operator runs an external job that watches `birthDate` (extended-account-field) + access `created` timestamp + chosen jurisdiction's age of majority (typically 16 EU / 13 US under COPPA / etc.) and triggers a re-consent prompt at the crossing date. **Multi-holder consent**: supported by the array form above; the operator's app code at access-mint time enforces "both parents must accept" (or whichever jurisdiction-specific rule applies) before calling `accesses.create`. Each parental-holder consent event independently satisfies the access-history record; revocation of any one of them is the operator's signal to revoke or scope-down the access (per Q19 + Q28 mechanisms). HDS: facilitated (effort saved: low) (mode: storage) HDS neither knows nor validates a subject's age; the default account schema is age-blind. Age and parental-authority verification happen in the controller's registration/consent UX, and the resulting artefacts can travel alongside the access via clientData conventions. Detail: Conventions let the controller record how age was verified and pointers to parental-consent events (single- or multi-holder). The parental-consent event format is not shipped by default; controllers targeting paediatric use-cases author it themselves. Re-verification at age-of-majority transitions is an external job the controller runs. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Verify age and parental authority in your UX and record the artefacts; HDS stores them but performs no age checks. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.10 — Processing of personal data relating to criminal convictions and offences Requirement: Processing of criminal-conviction/offence data is allowed only under official authority or where authorised by law with appropriate safeguards. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-10 PRYV PLATFORM: facilitated (mode: primitive) Same pattern as Art. 9 special-category data: dedicate a `criminal-records/*` stream subtree, scope every access tightly, record the Art. 10 legal- basis-by-law citation in `access.clientData.art10_basis`. Pryv has no role in deciding whether a given processing instance falls under "official authority", that's your legal judgement. HDS: facilitated (effort saved: medium) (mode: primitive) Same pattern as Art.9: a dedicated subtree, tightly scoped accesses, and the Art.10 legal-basis citation recorded on the access clientData. HDS has no role in deciding whether a given processing instance falls under official authority — that is the controller's legal judgement. Detail: Where such data is processed, the controller designs an isolated stream subtree and records the by-law basis on each access; the audit log then captures every read and write under that access. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Confirm your legal authority to process such data and record the basis; isolate the data in a dedicated, tightly scoped subtree. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.12 — Transparent information, communication and modalities Requirement: The controller must provide concise, transparent, intelligible information and respond to data-subject requests within one month. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-12 PRYV PLATFORM: facilitated (mode: storage) Pryv preserves whatever notice / consent text you presented to the subject, immutably, versioned, retrievable later. The response operations (Art.15-22) execute in sub-second; the 1-month rule is your process target, not a software limit. Detail: Information artefacts (notice, consent text, lawful-basis explanation) can live in `access.clientData` and/or in `consent/request-cmc` events. Both are immutable / versioned, so the subject sees the same text that was originally presented, addressing the "concise, transparent, intelligible" requirement at the artefact level. Whether the artefact itself is concise + intelligible is your editorial responsibility. HDS: facilitated (effort saved: medium) (mode: storage) HDS preserves the notice and consent text presented to the subject — immutably, versioned, retrievable later — and the rights operations (Art.15-22) execute in sub-second, so the one-month deadline is a process target rather than a software limit. Conciseness and intelligibility of the text are the controller's editorial responsibility. Detail: Information artefacts live in access clientData and/or consent events; both are versioned, so the subject can be shown the same text originally presented. The DSAR turnaround procedure HDS runs as operator is available on request. Evidence: internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Write concise, intelligible notices and run a request-handling process that meets the one-month deadline. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Receive the preserved notice/consent text and exercise your rights through the platform. ## gdpr Art.13 — Information to be provided where data are collected from the data subject Requirement: Controller identity, purposes, legal basis, recipients, retention and rights must be provided at the time of collection. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-13 PRYV PLATFORM: facilitated (mode: storage) The information items split across two operator-controlled surfaces: - **Deployment-wide** (controller identity, DPO contact, Terms of Service): the `serviceInfo` fields `home`, `support`, `terms`, propagated to every client app via `GET /service/info`; `app-web-auth3` renders them in its consent UI by default. Full convention treatment in `context/service-info-conventions.md`. - **Per-access** (purposes, lawful basis, recipients, retention, the specific rights notice): `access.clientData` per the convention family in `context/client-data-conventions.md`, `lawful_basis`, `purpose`, `transfer_basis`, `retention`, `consent`, `consent_event_id`, etc. (or a `consent/request-cmc` event when using CMC). Pryv preserves them immutably with version chain (`?includeHistory=true`); your app surfaces them at the right moment. HDS: facilitated (effort saved: medium) (mode: storage) HDS provides two surfaces to carry the disclosures: deployment-wide service info (controller identity, DPO contact, terms) returned to every client app, and per-access clientData (purposes, basis, recipients, retention, rights notice). HDS preserves them immutably; the controller authors the content and surfaces it at collection time. Detail: The service-info fields propagate to consent UIs automatically; the per-access convention fields carry the activity-specific disclosures with a version chain. Whether the wording satisfies Art.13 is the controller's responsibility. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [connects, own-records, third-parties, analytics, secondary-use] Author and present the Art.13 disclosures when you collect, and keep your own record of what was shown and when. HDS's own notices cover the vault, not your processing. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.14 — Information to be provided where data have not been obtained from the data subject Requirement: The same disclosures as Art.13 must be provided within a reasonable period when data are obtained indirectly. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-14 PRYV PLATFORM: facilitated (mode: storage) When you ingest data into Pryv from third parties (not directly from the subject), you still owe the same disclosures as Art.13. Pryv lets you record the disclosure artefact alongside the data, same as direct collection (`access.clientData` or a `consent/*` event), and the audit log proves when disclosure happened, useful when the 1-month / first-contact deadlines come into question. Detail: Where the data came from (the source) is an Art.14(2)(f) disclosure item, record it in `event.clientData.source` or in a dedicated provenance stream. Together with the access carrying the disclosure-notice text, you have the full Art.14 artefact set retrievable per subject. HDS: facilitated (effort saved: medium) (mode: storage) When the controller ingests data from third parties, HDS lets the disclosure artefact (incl. the source under Art.14(2)(f)) be recorded alongside the data, the same way as for direct collection, and the audit log proves when disclosure happened against the one-month/first-contact deadlines. Detail: Provenance can be recorded on the event clientData or a dedicated stream; combined with the disclosure-notice text on the access, the controller has the full Art.14 artefact set retrievable per subject. Evidence: internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [connects] Record the data source and present the Art.14 disclosures within the required period. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.15 — Right of access by the data subject Requirement: Right to obtain confirmation, access and a copy of personal data plus supplementary information. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-15 PRYV PLATFORM: implemented Your subject, holding a personal token, reads everything via the standard Pryv API, events, streams, accesses (with full history), audit records. The supplementary information (purposes, recipients) is in `access.clientData` when you recorded it there. For ready-made bundling, the `pryv-account-backup` npm tool walks the subject's API endpoints and produces a downloadable folder, operator-independent (the subject runs it with their own credentials). Detail: Subject-side reads via standard endpoints (all reachable on v2): - `events.get`: all events - `streams.get`: all streams - `accesses.get ?includeHistory=true`: accesses + version chain - `events.get ?streams=[':_audit:*']`: audit log (the dedicated `/audit/logs` route was removed 2026-06-15; audit is a regular datastore mounted on the `:_audit:*` streams) - `webhooks.get`: webhook subscriptions - `GET /events//series`: HF data points per series-event Attachments downloadable via the events API. `pryv-account-backup` v0.6.0 (shipped 2026-06-15; preceded by v0.4.0 2026-05-27 + v0.5.0 2026-06-13) covers, via its CLI flavour, every read-side resource: account, profiles, app profiles, streams, accesses (current + revoked/expired + opt-in per-access version history), events (monthly-chunked initial + incremental via `modifiedSince`), audit-as-events, HF series data points, webhooks, attachments, plus a per-file sha256 integrity manifest. The Art.15(1)(c) disclosure-history elements are in the raw export by default. The DSAR-completeness work is fully shipped, `proposals/account-backup-dsar-completeness.md` is `Status: SHIPPED`, all chips discharged. (The browser-webapp flavour omits attachments / HF series / webhooks / manifest, route subjects needing those to the CLI.) HDS: implemented (effort saved: high) HDS is user-centric by construction: a subject holding their personal token reads everything via the standard API — events, streams, accesses with history, and the audit log. HDS publishes the app-portability self-service web app (subject signs in, downloads a portable ZIP set) as the canonical access path, built on the pryv-account-backup library. Detail: All read-side resources are reachable: events, streams, accesses with version chain, audit-as-events, webhooks, HF series and attachments. The supplementary information sits in the access clientData where whoever granted the access recorded it there. The subject can either drive the API directly or use app-portability (operator-hosted at portability.hds.ngo / demo-portability.datasafe.dev); the ZIPs include an HDS provenance manifest (data-model version, deploy URL, completion timestamp) and a portable sync-state for incremental re-runs. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, doc:https://github.com/healthdatasafe/app-portability, internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [connects] Answer access requests for the copy and the records you hold. For data still in the vault the individual reads it directly from their own HDS dashboard, so that half of the request is not yours to serve. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Read or export your full data set directly via the API or the backup tool. ## gdpr Art.16 — Right to rectification Requirement: Right to have inaccurate personal data rectified without undue delay. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-16 PRYV PLATFORM: implemented `events.update` rectifies an event; event versioning preserves the prior (inaccurate) value for traceability, addressing the Art.5(1)(d) accuracy principle without losing the audit trail. Detail: Rectification mechanics: - **API**: `events.update` (PUT /events/:id) writes the new value AND emits a new event version. The route validates the updated payload through the same ajv-draft-04 pipeline as `events.create` (`components/api-server/src/methods/ events.ts:564` middleware chain), so a "rectification" that itself fails schema validation is rejected, you can't replace one inaccurate value with another that violates the type's structural constraints. - **History retrieval**: `GET /events/:id?includeHistory=true` returns the full version chain. The history is queried via `mall.events.getHistory(userId, eventId)` (same file line 185) and exposed at the implementer's API surface when requested. - **Audit trail**: every `events.update` call is in the audited methods set (`components/audit/src/ApiMethods.ts`). The audit log records method + access ref + timestamp; per the audit-minimality posture (Q9), the request body is NOT captured, the history chain on the event itself is the durable record of the prior value, not the audit log. - **Detection of inaccuracy**: out of scope at the platform layer. Pryv enforces structural validity at ingest (ajv schema validation); semantic inaccuracy detection is the implementer's app responsibility. See `context/data-accuracy-structural-vs-semantic.md`. HDS: implemented (effort saved: high) HDS rectifies an event with a single update call that preserves the prior value as a new version, so accuracy is corrected without losing the audit trail. The updated payload is schema-validated, so a rectification cannot introduce a structurally invalid value. Subjects can inspect their full record (including version history) via the app-portability self-service tool to identify what needs rectifying before raising a request. Detail: The version chain is retrievable on request, and every update is in the audited method set. Detection of inaccuracy is semantic and stays with the controller's app; HDS guarantees structural validity at ingest. The app-portability ZIPs include events, streams and (opt-in) per-access version history, so a subject can audit their own data end-to-end before filing a rectification claim. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, internal:hipaa/policies/integrity, internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Correct inaccurate data in the copy and the records you hold. Data in the vault is corrected by the individual, or by HDS at their request, not by you. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Request rectification, which is applied while preserving the prior value for traceability. ## gdpr Art.17 — Right to erasure ("right to be forgotten") Requirement: Right to obtain erasure without undue delay where one of the enumerated conditions applies. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-17 PRYV PLATFORM: configurable Per-user erasure is a single API call (`system.users.delete`). Whether erasure extends to your backups depends on the storage engine you chose, SQLite per-user folders are deletable from filesystem backups; PostgreSQL requires a backup-rotation policy to complete erasure. Detail: Per-engine behaviour for the live data: - SQLite, each user is a separate file under the user-data directory. File deletion removes the user from filesystem backups (depending on your backup tool's per-file semantics). - PostgreSQL, row-level erasure only. Backups are DB-engine-level snapshots; per-user erasure within a backup file requires either backup rotation (oldest pruned per policy) or a backup-rewriting procedure you build yourself. Event attachments follow your `storages.file.engine` choice (filesystem / s3 / postgresql, the latter two since open-pryv.io 2.0.0-rc.2). Account deletion routes attachment removal through the fileStorage interface, so live copies are erased on all three engines. Backup residue differs per engine: filesystem attachment directories follow your file-backup tool's semantics; S3 buckets may retain deleted-object versions (disable versioning or add a lifecycle rule if erasure must extend there); PostgreSQL-stored attachments live in the same `pg_dump` artefacts as user rows, so the backup-rotation policy above covers them with no extra step. Erasure here is **caller-triggered**, the subject (or operator on their behalf) issues the DELETE call. The **scheduled / automatic** erasure obligation under Art.5(1)(e) "storage limitation" is operator-owned by design, see Art.5 detail + `context/data-retention-operator-owned.md` for the retention- job pattern that composes `events.delete` + `auth.delete` + the audit log. `bin/backup.js` supports per-user backup files alongside DB-engine backups; using per-user backups improves erasure semantics regardless of engine. Audit-log erasure converges across engines (since 2026-05-27, open-pryv.io master `891090d` + `853e1cb`). `auth.delete` now includes an explicit `deleteAuditDataStorage` middleware that calls `auditStorage.deleteUser(userId)` regardless of the configured audit engine. SQLite + PostgreSQL audit deployments converge on the same end-state: zero audit rows for the deleted subject. The `[USAD]` test suite asserts engine-agnostically via `auditStorage.forUser(userId).countEvents() === 0`. Operator setting `audit.onUserDelete` (shipped in `405b3a1`) gates the behaviour: - `erase` (default), runs the audit erasure (GDPR Art.17 / CCPA §1798.105 / PIPEDA Principle 4.5 default). - `keep`: skips the wipe with an info-log. For HIPAA §164.316(b)(2)(i) (6-year audit retention), MDR Art.10(8) (10-year device-history retention), or any regime keeping the audit under a separate lawful basis (GDPR Art.17(3)(b)). The operator documents the retention in their DPIA. - `pseudonymise`: REFUSED AT BOOT by `config/plugins/config- validation.js`. The `auth.randomAlias` primitive it builds on has now shipped (`accesses.create {randomAlias:true}`); the audit-row PII null-out mode itself (composing the alias into audit records while preserving forensic value) is still the outstanding piece before this mode can be enabled. SQLite-audit + `keep` mode known caveat: the parent `deleteAuditData` filesystem-wipe step still runs after `deleteAuditDataStorage` returns from `keep`, so the per-user `.sqlite` audit file is removed regardless. PG-audit deployments get `keep` semantics as designed (rows survive). Operators wanting `keep` on SQLite need a PG audit migration or a follow- up teaching `deleteAuditData` to skip when `mode === 'keep'`. HDS: configurable (effort saved: medium) Per-user erasure is a single API call that deletes the subject's live data, attachments and audit rows. How far erasure extends into backups depends on the storage engine and backup-rotation policy; HDS operates a documented backup and rotation regime as operator. Scheduled/automatic erasure under storage limitation is a known gap (no retention automation). Subjects are advised to use the app-portability self-service tool to keep a portable copy of their data **before** requesting erasure — the public deletion page on healthdatasafe.org cross-links accordingly. Detail: Account deletion removes live events, attachments and audit rows engine-agnostically. Backup residue differs by engine and is bounded by the rotation policy. Erasure here is caller-triggered; automated retention deletion must be composed externally by the controller. The operator backup/erasure procedure is available on request. The platform's `audit.onUserDelete: pseudonymise` mode (null out audit-row PII via the now-shipped `randomAlias` primitive while preserving forensic value) remains unavailable — refused at boot upstream until the audit-row null-out lands — so erasure-vs-audit-retention on HDS resolves through `erase` (default) or `keep`, not pseudonymisation. The operator-facing healthdatasafe.org `/users/data-deletion` page surfaces the portability tool as the first step ("Before You Delete — Download a Copy") so the subject's right to a copy under Art.20 is exercised ahead of an irreversible erasure. Evidence: doc:https://www.healthdatasafe.org/users/data-deletion, doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, internal:gdpr/procedures/data-subject-rights, internal:gdpr/policies/data-retention, internal:hipaa/procedures/data-backup-plan PLANNED (platform, impact medium): The audit.onUserDelete setting ships and is deployed, with erase and keep both usable; its third mode, pseudonymise (audit-row PII null-out), is enumerated but refused at boot because the audit-row null-out itself is not implemented. This row's erasure-vs-audit-retention position stays partial until that lands upstream and HDS deploys it. IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy, own-records] Decide when an erasure obligation is triggered and invoke deletion; define your own retention schedule, since automation is not provided. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Request erasure of your account, applied across live data and audit rows. ## gdpr Art.18 — Right to restriction of processing Requirement: Right to obtain restriction — data stored but not processed — in defined circumstances. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-18 PRYV PLATFORM: configurable Restriction is achieved by mutating the access, scope-down via `accesses.update` (narrower permissions) or full revoke via `accesses.delete`. Versioning preserves the pre-restriction state so the change is auditable. No dedicated "restriction flag", the access mutation IS the restriction primitive. Detail: Article 18 envisions restriction as a temporary state where data is stored but not processed. With Pryv: - Data continues to live in events / streams (unchanged). - Processing (= API access through an access token) is restricted by lowering the relevant access's `permissions` to `none` on affected streams or by deleting the access. - The access-version chain proves when the restriction took effect and what state was in force before. You may also surface a restriction flag in `access.clientData.restriction_reason` for record-keeping (Art.30 register entry). HDS: configurable (effort saved: medium) Restriction is achieved by mutating the access: scope its permissions down or revoke it. Data continues to live in events and streams while the access change stops processing, and the version chain proves when the restriction took effect. There is no separate restriction flag — the access mutation is the restriction primitive. Detail: Restriction of what sits in the vault is the individual's act: they lower the relevant access's permissions on the affected streams, or revoke it outright, with immediate effect and a version chain proving when. An organisation restricting the copy it holds stops processing that copy and records the reason in its own register. Where a restriction concerns a covered-entity or partner relationship, the reason can also be recorded on the access clientData for that party's Art.30 register. Evidence: internal:hipaa/policies/access-control, internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Restrict your own processing: stop using the copy and the records you hold, keep them, and record the reason. Revoking the grant that feeds you is the individual's act, not a restriction you apply on their behalf. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Request restriction, applied as an access scope-down that halts processing while preserving the data. ## gdpr Art.20 — Right to data portability Requirement: Right to receive personal data in a structured, commonly used, machine-readable format and to transmit it to another controller. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-20 PRYV PLATFORM: implemented `events.get` + `streams.get` return canonical JSON validated against the data-types schemas, structured, commonly used, machine-readable. Attachments downloadable. No proprietary lock-in: another Pryv operator can import the data into a new account via standard write APIs. Detail: Export shape is the same JSON the data subject (or their delegated app) would see at any time via the API. You can wrap this in a "download my data" UI; the underlying primitive needs no special export endpoint. Direct controller-to-controller transmission (§2) is supported via the CMC capability flow: a single-event-scoped capability access mints a URL the receiving controller can read once. **Portability of custom event types**: deployments using a custom event-type catalogue (via `service.eventTypes`, see `context/custom-event-type-catalogues.md`) export the same canonical JSON shape for custom types as for upstream `pryv/data-types` types, they're first-class in the validation + serialisation pipeline. Receiving Pryv.io deployments that ship the same catalogue (or a superset) can import the events without loss. A receiving deployment without the custom catalogue would reject unknown types at write-time validation, the implementer ensures schema alignment between transmitting + receiving operators when relying on §2 controller-to-controller transmission. **Calendar interoperability (adapter):** beyond raw JSON, Pryv data can be exposed in a ubiquitous interchange standard. The calendar adapter serves selected events as an iCalendar (RFC 5545) subscription feed any calendar client can read, and ingests an external iCalendar feed back into Pryv as `calendar/ical-event` events (well-known fields in structured `content`, the verbatim VEVENT in `clientData._raw`). Adapters are discoverable via the `/service/info` `adapters` field. This widens portability from machine-readable JSON to a standard the subject's existing tools already consume, lowering the implementer's integration burden. HDS: implemented (effort saved: high) Reads return canonical JSON validated against the data-type schemas — structured, commonly used and machine-readable — with attachments downloadable and no proprietary lock-in. The app-portability web app packages a full account into a series of ZIP files (events, streams, accesses, attachments, audit, HFS, webhooks) that the subject downloads in one self-service flow. Another HDS/Pryv operator can re-import via standard write APIs; controller-to-controller transmission is also available via the CMC capability flow. Detail: The export shape is the same JSON the subject sees via the API. The ZIP layout matches the upstream pryv-account-backup CLI restore format, so a subject can later re-hydrate to a self-hosted or partner-hosted node. HDS adds an `hds-manifest.json` in the final ZIP (data-model version pin, app-portability version, deploy URL, completion timestamp, total bytes) for audit-trail purposes. For custom event-type catalogues, schema alignment between transmitting and receiving operators is the controller's responsibility when relying on direct transmission. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, doc:https://github.com/healthdatasafe/app-portability, internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Supply the data you hold in a portable format on request. Portability out of the vault is between the individual and HDS; where a direct controller-to-controller transmission is asked for, align on the schema. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Export your data in portable JSON and have it transmitted to another controller. ## gdpr Art.21 — Right to object Requirement: Right to object to processing based on legitimate or public interest; absolute right to object to direct marketing. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-21 PRYV PLATFORM: facilitated (mode: primitive) Pryv doesn't do profiling or marketing itself, but if your app does either using Pryv-stored data, your subjects have the right to object. **The mechanism is the same as Art.7(3) withdrawal (Q19)**, `DELETE /accesses/:id` or `accesses.update` to narrow permissions; Pryv's primitives are basis-agnostic. The legal distinction between Art.21 objection (legitimate-interests / public-interest basis) and Art.7(3) withdrawal (consent basis) is semantic, not technical. Record the objection on the access's `clientData` per the consolidated convention catalogue at `context/client-data-conventions.md`. Detail: For direct marketing (absolute right per §2), the typical pattern is: - Subject submits objection (via your app's UI). - You record the objection event (e.g., a custom `consent/object-marketing` event or a flag in `account.clientData.marketing_objection`). - You revoke or narrow the access used by the marketing process → versioned, auditable. - Subsequent marketing-process runs see the access is gone / narrowed → no processing happens. For Art.21(1) objections (legitimate interests / public interest), same pattern; you also need a "compelling legitimate grounds" review process before deciding to override the objection. Record the operator-side review outcome on the access's `clientData.objection_outcome` (one of `"honoured"`, `"overridden_compelling_grounds"`, `"out_of_scope"`) plus a free-text `clientData.objection_rationale` pointing at the legal-basis document, both versioned + audit-traceable via access-versioning (`context/access-versioning.md`). For Art.21(5) transparency ("right to object presented clearly and separately from any other information at the time of the first communication"), same convention family as Art.7 consent text: persist the notice on `clientData.objection_notice` so the version chain proves what the subject was told when the access was minted. See `context/client-data-conventions.md` for the full catalogue. HDS: facilitated (effort saved: medium) (mode: primitive) HDS performs no profiling or marketing itself. Where a controller's app does, the objection mechanism is the same access revoke/scope-down as consent withdrawal, and the objection (and any compelling-grounds outcome) can be recorded on the access clientData. The legal distinction between objection and withdrawal is semantic, not technical. Detail: For direct marketing the objection is recorded and the marketing access narrowed or revoked, so subsequent runs find no scope; in the vault the revocation is the individual's to make, and an organisation acting on its own copy stops the processing objected to at its own end. For legitimate-interest objections a compelling-grounds review is run and its outcome recorded on the access or in the objector's own register; all of it is versioned and auditable. Evidence: internal:hipaa/policies/access-control, internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [connects, analytics, secondary-use] Run the compelling-grounds assessment where applicable, then stop the processing objected to in your own systems. The individual narrows or withdraws their grant themselves. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) Object to processing; the objection is applied through the access primitive and recorded. ## gdpr Art.19 — Notification obligation regarding rectification / erasure / restriction Requirement: The controller must communicate any rectification, erasure or restriction to each recipient, unless impossible or disproportionate. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-19 PRYV PLATFORM: facilitated (mode: evidence) The recipients are derivable from Pryv data, the accesses the controller has minted to third parties. When you exercise an Art. 16-18 action that affects events held by those recipients, iterate the active accesses and notify each holder out-of-band. For CMC-paired counterparties, the `consent/revoke-cmc` or a custom `notification/rectification` event provides a structured notification channel. HDS: facilitated (effort saved: low) (mode: evidence) Who can enumerate recipients depends on who is asking. HDS, as controller of the vault, can see the accesses an individual has granted, and the individual sees the same list live in their own dashboard. An organisation that received data cannot: it knows only the onward disclosures it made itself, so its Art.19 notification runs against its own records. CMC-paired counterparties have a structured notification channel. Detail: The set of recipients an individual has granted is reconstructable from the active accesses, by the individual and by HDS. For an organisation acting on its own copy, the recipient list is the one it keeps of its own disclosures. The out-of-band notification to each, and the impossibility or disproportionality judgement, belong to whoever carries the duty. Evidence: internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [connects, third-parties] Notify each recipient you have passed data on to. The list is the one you keep of your own disclosures; you cannot enumerate who else the individual has granted access to. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.22 — Automated individual decision-making, including profiling Requirement: Right not to be subject to a decision based solely on automated processing producing legal or similarly significant effects, subject to exceptions. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-22 PRYV PLATFORM: facilitated (mode: evidence) Pryv doesn't run automated decisions, that's your application logic. What Pryv contributes when Art.22 applies: (1) the audit log proves which inputs were read for the decision; (2) the decision output can be written as a Pryv event with the input reference + the decision logic version captured in `clientData`, making "human intervention" requests tractable (the subject can locate the specific decision record); (3) the consent basis for §2(c) lives on the access's clientData like every other consent record. Detail: Recommended pattern when you run Art.22 processing: - Mint a dedicated access for the automated-decision app with `clientData.processing_purpose = "automated_decision_making"` + `clientData.art22_basis = "(a) contract" | "(b) law" | "(c) consent"`. - Write the decision output as an event on a designated `decisions/*` stream with `clientData.input_audit_ref` pointing back to the audit-row range that fed it + `decision_logic_version`. - When a subject requests human intervention, your portal looks up that event and presents the trail to the human reviewer. HDS: facilitated (effort saved: low) (mode: evidence) HDS runs no automated decisions — that is the controller's application logic. Where Art.22 applies, the audit log proves which inputs were read, the decision output can be stored as an event referencing those inputs and the logic version, and the §2(c) consent basis lives on the access clientData like any other consent record. Detail: The individual grants the decision app its own access; the app writes the decision output with an input-audit reference and a logic version, and that trail is what supports a later human-intervention request. HDS supplies the evidentiary substrate, not the decision. Evidence: internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [analytics] Implement the safeguards (basis, human intervention) and record the decision trail; the evidentiary primitives are provided. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.24 — Responsibility of the controller Requirement: The controller must implement and be able to demonstrate appropriate technical and organisational measures, proportionate to the risk. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-24 PRYV PLATFORM: facilitated (mode: evidence) Art. 24 is the umbrella controller-accountability obligation that ties every other Chapter-IV row together. Pryv contributes the technical- measures substrate (this matrix enumerates it explicitly) + the technical-measures demonstrability (audit log + access version chain are the evidence layer). The organisational- measures programme is yours. HDS: facilitated (effort saved: low) (mode: evidence) Art.24 is the umbrella accountability obligation. HDS contributes the technical-measures substrate enumerated across this matrix and the means to demonstrate it (audit log plus access version chain). The organisational-measures programme is the controller's. Detail: HDS supplies access control, transport encryption, monitoring and the evidence layer as controller of the vault rather than as anyone's processor, and offers no Art.28 DPA for this product because it cannot satisfy Art.28(3). An organisation assembles those measures into its own accountability programme and carries the demonstrability burden at the organisational level. Evidence: internal:hipaa/policies/access-control, internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Build and maintain your accountability programme, citing HDS technical measures and your own organisational controls. IMPLEMENTER [processor] coverage: documented applies_when: always Where you act as a processor, evidence your own measures and operate on documented controller instructions. Templates to sign: dpa ## gdpr Art.26 — Joint controllers Requirement: Where two or more controllers jointly determine purposes and means, they must allocate their responsibilities in a transparent arrangement. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-26 PRYV PLATFORM: facilitated (mode: awareness) **CMC is NOT a joint-controller pattern by default.** Pryv's CMC primitive requires **subject validation**, User A's `consent/accept-cmc` event is what authorises any cross-account data flow to User B's operator. Each operator remains the **sole controller** for their respective user's data; the lawful basis for B's processing of A's data is A's CMC consent record (Art.6(1)(a)), not a controller-to-controller agreement. This is controller-to-controller transmission *via subject consent* (Art.20(2) lineage), not Art.26 joint controllership. Real Art.26 fires only if Operator-X + Operator-Y separately decide to jointly process a category of subjects' data, outside the CMC primitive. Detail: **Art.26 test**: "two or more controllers JOINTLY determine purposes and means". In a CMC share: - The **purpose** is declared in A's `consent/request-cmc` event (or accepted from B's request), A determines whether to consent. - The **means** are A's access permissions + B's access scope, both anchored to A's accept event. - Neither operator decides on behalf of both; subject A is the determiner. So a CMC share does NOT trigger Art.26. It's covered by: - **Art.6(1)(a)** (consent), A's consent is the lawful basis for B's operator to process A's data. - **Art.20(2)** (data portability, transmit to another controller), the act of CMC delivery is "transmission to another controller" with subject's consent. - **Art.13/14** (transparency), each operator carries their own transparency obligation to their respective user; A's operator informs A about who receives the data; B's operator informs B about what data they received + the lawful basis (A's consent). **Where Art.26 actually applies**: when two operators run a joint research programme, joint health platform, or shared-purpose service where both decide on processing independently of subjects' individual choices. In that case, the arrangement IS the operator-side contract; Pryv's contribution is `clientData.joint_controller_arrangement` on the relevant accesses (point to the written agreement) + the "essence" of the arrangement in `clientData.privacy_notice` for Art.26(2). This is operator-edited metadata, no Pryv primitive enforces it. Full CMC-vs-Art.26 reasoning in `context/cmc-consent-primitives.md`. HDS: facilitated (effort saved: low) (mode: awareness) HDS's cross-account sharing (CMC) is not joint controllership: it requires the subject's validation, so each operator stays the sole controller for their user and the lawful basis is the subject's consent, not a controller-to-controller agreement. Real Art.26 fires only when two controllers separately decide to jointly process data — outside the CMC primitive. Detail: Where genuine joint controllership exists, the arrangement is the controllers' own contract; HDS can carry a pointer to it and the essence of the arrangement on the relevant access clientData, but no platform primitive enforces the allocation. Evidence: internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [third-parties] If you are a joint controller, conclude the Art.26 arrangement and make its essence available to subjects. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.27 — Representative of controllers / processors not established in the Union Requirement: A controller or processor not established in the Union must, where Art.3(2) applies, designate an EU representative in writing, subject to exemptions. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-27 PRYV PLATFORM: out-of-scope Representative designation is a contractual + regulatory registration step. No software role. HDS: out-of-scope Designating an EU representative is a contractual and regulatory registration step with no software role. Where HDS itself processes for EU subjects from a non-EU establishment, HDS makes its own designation; the controller makes its own. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] If Art.3(2) applies to you and no exemption holds, designate an EU representative in writing. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.29 — Processing under the authority of the controller or processor Requirement: A processor and anyone acting under its or the controller's authority must process personal data only on the controller's instructions. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-29 PRYV PLATFORM: facilitated (mode: primitive) "Only on instructions" is enforced operationally through the access primitive, workforce / contractor / app accesses are scoped to specific streams + levels per the controller's instructions, and the audit log proves what was actually done. Violations show as out-of-scope access attempts or unauthorized method calls in the audit data. HDS: facilitated (effort saved: high) (mode: primitive) "Only on instructions" is enforced operationally through the access primitive: workforce, contractor and app accesses are scoped to specific streams and levels, and the audit log proves what was actually done. HDS binds its own staff to that discipline for the vault it controls. It is not processing on another organisation's instructions here, so this article describes the persons under that organisation's own authority rather than HDS's relationship to it. Detail: Out-of-scope access attempts and unauthorised method calls surface in the audit data, making instruction violations detectable. The substantive instructions binding an organisation's own staff and processors come from that organisation, not from any agreement with HDS. Evidence: internal:hipaa/policies/access-control, internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy, third-parties] Art.29 covers people acting under YOUR authority: bind your staff and your own processors to act only on your instructions. It does not describe your relationship to HDS or to the vault, where processing follows the individual's permissions rather than yours. IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy, third-parties] Process only on documented controller instructions and keep your staff within their scoped accesses. Templates to sign: dpa ## gdpr Art.25 — Data protection by design and by default Requirement: The controller must integrate data-protection principles into the design and ensure privacy-protective default settings. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-25 PRYV PLATFORM: facilitated (mode: infrastructure) Pryv's whole architecture leans privacy-by-design, per-user storage isolation, stream-scoped permissions, separate personal/app/ shared access types, privileged data on system streams. Your defaults (token scopes, audit-on, retention) are the part still in your hands. Detail: Pryv's architecture is privacy-by-design **by founding pattern**, not retrofitted. Canonical treatment + the 12-default catalogue: `context/privacy-by-design-and- default.md` (matrix-internal); customer-facing surface [`pryv.github.io/guides/privacy-by-design.html`](https://pryv.github.io/guides/privacy-by-design.html). **Architectural commitment (§1)**: the topology: Data Governance + Access Control + Audit-per-Subject as separate layers that every process traverses; not direct personal-data access with after-the-fact audit (the PbD anti-pattern). Process registry is self-documented via `GET /accesses` + audit log (= the Art.30 records-of- processing register, derivable on demand). **Data-model commitment**: streams + events segregated by data-subject AND context. Granular consent (each access targets a specific stream subtree, not a wall of tables); adapt data collection per subject without schema migration. Substrate for Art.5(1)(c) minimisation + Art.7 granular consent + Art.17 erasure + Art.20 portability. **By-default catalogue (§2)**: 12 platform defaults that satisfy "by default, only data necessary for each specific purpose are processed": 1. **Default-deny on permissions** (empty `permissions: []`). 2. **Audit-on by default** (invariant, no opt-out). 3. **TLS enforced** (optional Let's Encrypt integration). 4. **Hosting region pinned per user** (Q12 architectural residency). 5. **Stream-permission granularity** (Q22, no "public" tier exists). 6. **Data-minimal audit** (Q9, never captures request body). 7. **Schema validation at ingest** (Q21, ajv-draft-04 rejects out-of-shape payloads by default). 8. **Zero mandatory subprocessors** (Q23, every integration opt-in). 9. **Audit-minimal logger** (Q23, `inspectAndHide` credential redaction invariant, `[BIH1-6]` tests). 10. **CMC requires explicit subject consent** (`consent/accept-cmc` blocking). 11. **PlatformDB encrypted secrets** (LE + observability patterns). 12. **Withdrawal API exists by default** (Q19, `DELETE /accesses/:id` always available). **Still in your hands (Art.25 §2, operator's by-default settings)**: - Are app tokens minted with the smallest possible scope? - Is your subject's notice-of-collection on by default? - Is data retention set to the shortest necessary period? - Is your auth UI surface using the opt-in pattern (privacy-by-default UX from the dev-site reference) rather than the standard "by continuing you agree" anti-pattern? Privacy-enhancing technologies (PETs) catalogued in the dev-site guide: pseudonymisation (partial, `ALIASES` backlog upgrades), proxy re-encryption (`E2E-ENCRYPTION` backlog + the github.com/perki/test-proxy-re-encrypt PoC), homomorphic encryption + differential privacy + MPC (out-of-scope at platform layer; implementer's enrichment path). HDS: facilitated (effort saved: high) (mode: infrastructure) The HDS architecture is privacy-by-design by founding pattern: per-user storage isolation, default-deny stream-scoped permissions, separate personal, app and shared access types, privileged data on system streams, and audit-on by default. The vault's own defaults are HDS's to set. The defaults an organisation controls are the ones in what it builds: how narrow a grant its application requests, whether its notices default on, and how long it keeps what it receives. Detail: Default-deny permissions, audit-by-construction, enforced transport encryption and per-user residency pinning ship as platform defaults. An organisation building on the vault decides the scope of the grant it asks for, the defaults of its own consent and notice surfaces, and the retention of any copy it keeps. Evidence: internal:hipaa/policies/access-control, internal:gdpr/policies/data-retention IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Set privacy-protective defaults in what you build: request the narrowest grant you need, write opt-in notices, and keep what you receive no longer than necessary. The vault's own defaults are HDS's to set. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.28 — Processor Requirement: Processing on behalf of a controller must be governed by a contract setting out subject matter, duration, nature, purpose, data types and the parties' obligations. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-28 PRYV PLATFORM: facilitated (mode: storage) When the Pryv operator and the controller are distinct legal entities (typical SaaS arrangement), the operator is the Art.28 processor. Pryv-the- software provides the technical substrate the §1 "sufficient guarantees" evaluation rests on (this matrix enumerates it); the data-processing-agreement (DPA) under §3 is the operator's contract. Audit log + access primitives carry "documented controller instructions" (§3(a)) and the records that demonstrate compliance (§3(h)). Detail: **Zero mandatory subprocessors.** Pryv-the-software ships with no required third-party-service relationships. The default deployment (operator's chosen cloud provider only, opaque to Pryv) has no sub-processors from the platform's perspective. Every external integration is opt-in through config. **Opt-in integration inventory (§2 + §4 sub-processor list when activated)**, see `context/subprocessor-posture-and-data-flow.md` for code anchors + per-integration data-flow analysis: | Config gate | Subprocessor | What flows out | |---|---|---| | `letsEncrypt.enabled: true` | LE (or any `letsEncrypt.directoryUrl` ACME CA) | hostnames only for ACME challenges; **no user data** | | `services.email.smtp.*` | operator's SMTP relay | email + name + one-time tokens (templated bodies), PII. **Pryv recommends per-core SMTP configuration**, the `services.email.smtp.*` config block is per-core, so an EU core routes mail through an EU SMTP relay independently of a US core's relay. Use this when residency is a hard requirement (e.g., EU subjects' password-reset emails never touching a US-jurisdiction relay) | | `services.mfa.mode: enabled` + `sms.endpoints[*]` | operator's SMS provider | phone number + MFA code, PII | | `observability.enabled: true` + an OTLP endpoint | Whichever backend that endpoint belongs to, any OTLP-ingesting service, or none at all if it points at a collector the operator hosts | per-method metrics + sanitized error stack traces, built from a fixed allow-list before egress (see Layer 3 below) | | `service.eventTypes: https://...` | upstream catalogue host | **no personal data flows out**, fetch-only of JSON Schema fragments | **Let's Encrypt posture (operator clarification)**: ships as a **dev-platform facilitator**: the easy on-ramp for `*.pryv.me`- style dev clusters. **Production deployments should treat CA choice as an operator decision.** Keep LE if its compliance posture matches yours, swap to a commercial CA / internal CA / air-gapped issuance pipeline if not. The ACME orchestrator reads `letsEncrypt.directoryUrl`, so any ACME-compatible CA drops in without code changes. **Data-flow guarantees that limit subprocessor exposure**, three real layers, each tested: 1. **Audit-by-construction (Q9)**: audit captures method + access ref + URL query (incl. content-query search values on the GET path, see `context/content-query-audit-semantics.md`) + integrity hash; **never the request body**; `auth=` query-string params stripped. `components/audit/src/Audit.ts:151-166`. 2. **Logger sanitization**: every `logger.{info,warn,error, debug}` call passes args through `inspectAndHide` (`components/boiler/src/logging.ts:253-298`): object keys `password`/`passwordHash`/`newPassword` → `'(hidden password)'`; string regex `auth=c[a-z0-9-]*` → `'auth= (hidden)'`; serialised JSON password fields → `'$1=(hidden)'`. Tested by `[BIH1]`-`[BIH6]` in `components/api-server/test/boiler-inspectAndHide.test.js` + `system-seq.test.js:533`. Honest scope: redacts credentials, not PII broadly, emails / usernames / event payloads only leak if a caller explicitly logs them. 3. **Observability allow-list** (when observability is opted into), telemetry is constructed by the platform from a compile-time allow-list at `components/business/src/observability/schema.ts` and shipped over OTLP/HTTP. No vendor or OpenTelemetry SDK runs in the process and nothing is auto-instrumented, so the emitted surface is fixed in source rather than filtered out of an agent's collection. Emitted: per-API-method call counts, duration histograms and error counts, labelled only with a method id from the platform's own API registry, a status class and an error code from the published error id list; service name and version, core FQDN and worker index; and, for server-side faults, the error class plus a stack trace with frames rewritten repository-relative. Request URLs, query and route parameters, bodies, headers, usernames, record identifiers, log records and error **message** text have no key in the schema and therefore no code path to the backend; datapoints outside the vocabulary are dropped and counted. Error reports are aggregated by fault and stamped at the reporting interval rather than the instant of failure, and the instance id is the machine hostname and never derived from the service URL, so the two correlation handles that would otherwise re-identify activity are removed. The destination is a URL plus an auth header, so an operator pointing it at a collector they host themselves has no third-party processor here at all. Claim to rely on: **anonymous by construction, with a residual correlation risk at very low traffic volumes** (where one error in an interval may be the only active user's). Where that residual applies, treat the telemetry as personal data and keep Art.28 in scope for an external destination. ⚑ **Correction of record:** before 2026-07-27 this layer was an in-process vendor agent whose scrubbing config lived in a file the agent does not discover, so it was inert and enabled deployments ran on vendor defaults (request URLs, `Host`, route parameters carrying the username, forwarded log records). That was fixed on 2026-07-27 and the agent was then removed entirely, because a control that works by enumerating what must not escape a collector that sees everything is only as strong as that collector's defaults. Full account: `context/subprocessor-posture-and-data-flow.md`. **§3(g) deletion / return of personal data at the end of provision**, `bin/backup.js` + `system.users.delete` cover both directions. **§3(h) auditability**: the operator demonstrates compliance partly via Pryv's audit log + this compliance matrix (evidence-backed assertion structure). **Future: machine-readable subprocessor inventory**: the planned `GET /system/admin/config/effective` admin route (`CONFIG-EFFECTIVE-EXPOSURE` per `UPDATE-TRIGGERS.md`) will expose the merged effective config per core as a single JSON artefact the operator's DPA register + Art.30 records-of-processing pipeline can consume directly. Until then, the operator reads `override-config.yml` + per-host overlays + identifies non-default integrations by hand. HDS: facilitated (effort saved: medium) (mode: storage) This article governs an organisation's engagement of its own processors. HDS is not one of them for the vault, and the arrangement is not available to negotiate: Art.28(3) requires processing on the controller's documented instructions and deletion or return of the data at the controller's choice, while HDS acts on the individual's permissions and cannot delete an individual's vault at a third party's direction. What HDS does carry is a disciplined subprocessor posture of its own: zero mandatory subprocessors, with every external integration (SMTP, SMS, observability) opt-in and inventoried with its data flow. The sufficient-guarantees evaluation of an organisation's own processors is that organisation's to make. Detail: HDS maintains a subprocessor register and hosting-provider attestations covering the providers it engages downstream, and signs the agreements that flow obligations to them. It offers no Art.28 data-processing agreement for the vault, because there is no arrangement for one to govern; an organisation placing data with HDS on its own behalf is a different arrangement, documented separately and outside this matrix. The audit log and access primitives remain available as demonstrability evidence for the processing an organisation does carry out. Evidence: internal:hipaa/registers/subprocessor-register, internal:hipaa/registers/hosting-provider-attestations, internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy, third-parties] If you engage processors of your own for the copy you hold, evaluate their guarantees and conclude an Art.28 DPA before processing begins. This is not an agreement with HDS: HDS is the controller of the vault, not your processor. Templates to sign: dpa IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy, third-parties] Sign the DPA, maintain your subprocessor inventory and bind any subprocessor on equivalent terms. Templates to sign: dpa, subprocessor ## gdpr Art.30 — Records of processing activities Requirement: Each controller and processor must maintain a record of its processing activities (purposes, categories, recipients, transfers, retention, security). Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-30 PRYV PLATFORM: implemented The combination of access + clientData + audit + (cross-account) CMC + data-residency IS your Article 30 register: who, what, why, when, recipients, transfers, retention, all derivable per-subject and per-time-window from primitives Pryv records continuously. Detail: Register field → Pryv data source: | Article 30 field | Pryv source | |---|---| | Controller / processor identity | your operator metadata + audit user identity | | Purpose | `access.clientData.purpose` (by convention) | | Categories of data subjects | derived from user-account metadata | | Categories of personal data | event `class/format` from data-types | | Categories of recipients | counterparty `access` (CMC pair) | | Transfers to third countries | CMC counterparty `apiEndpoint` host + chosen hosting | | Retention | `access.clientData.retention` + `access.expires` | | Security measures | covered in Art.32 | Audit row → access ref (with serial) → consent state at that moment. Recoverable per data-subject + per-time-window + per-purpose. PLANNED (feature, impact low): Chained / signed audit log makes the Article 30 register tamper-evident PLANNED (feature, impact medium): Read-only effective-configuration endpoint turns the §1(g) description of technical security measures into emitable evidence HDS: facilitated (effort saved: medium) (mode: evidence) The combination of access, clientData, audit, CMC and data-residency lets much of the Art.30 register be derived per subject and per time window: who, what, why, when, recipients, transfers, retention. A platform-generated, complete register is a known gap; each operator keeps its own. HDS maintains its own Art.30(1) controller record, populated with eight live processing activities. Its Art.30(2) processor record is deliberately empty and stays that way while HDS processes on no controller's instructions. Detail: Register fields map onto platform sources: purpose to access clientData, data categories to event class/format, recipients to counterparty accesses, transfers to counterparty host plus chosen hosting, retention to clientData and access expiry. The controller assembles and maintains the formal register; HDS provides the derivable inputs and keeps its own. Evidence: internal:gdpr/registers/records-of-processing PLANNED (doc, impact medium): HDS's processor-side register is populated with its live processing activities. What remains is narrower: retention periods are not set for the recruitment, CRM and contact-mailbox rows, and the Art.30(2) half stays empty until the first partner DPA is executed, which the register states rather than filling with a fictional row. IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy] Maintain your Art.30 register, drawing the technical fields from the platform's derivable inputs. IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy] Keep your own processor-side record of the processing you perform for each controller. Templates to sign: dpa ## gdpr Art.32 — Security of processing Requirement: The controller and processor must implement appropriate technical and organisational security measures: pseudonymisation, encryption, ongoing CIA, restoration and regular testing. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-32 PRYV PLATFORM: facilitated (mode: infrastructure) Multi-aspect article, Pryv implements several aspects for you (access control, encryption-in-transit, restoration) and provides configurable controls for others (encryption-at-rest, pseudonymisation, data residency). Organizational measures (regular testing, incident response procedures) stay in your court. Detail: Per-aspect: - Encryption in transit: IMPLEMENTED, TLS 1.3 via built-in Let's Encrypt integration; mTLS between cores in a cluster. - Encryption at rest: CONFIGURABLE, the `container-encrypted-volume` companion (opt-in `CEV_ENABLED`) provisions an encrypted volume covering the full user-data surface (events, attachments, series, audit, and PlatformDB) with a pluggable LUKS/gocryptfs backend and env/file/exec/clevis/aws-kms key provider; operator secrets in PlatformDB are additionally AES-256-GCM encrypted at the application layer. CEV protects data on the storage medium (stolen / decommissioned disks, off-host backups, snapshots); it does not defend a running container, and a core running rqlite outside a CEV container, or an external PostgreSQL, falls back to operator-side full-disk encryption. Event attachments inherit the at-rest controls of your `storages.file.engine` choice: filesystem encryption, S3 server-side encryption (SSE), or, with attachments stored in PostgreSQL, the same DB-level encryption that covers user rows. - Pseudonymisation: FACILITATED, system streams + custom event-type design; pseudonyms live in `clientData` or dedicated streams. - Access control: IMPLEMENTED, `permissions` enforce stream- level scope at every API call (technical control, not policy). - Authentication strength: IMPLEMENTED, `mfa.*` API methods, opt-in per `services.mfa.mode`. - Delegated-app authorization: IMPLEMENTED, the OAuth2 authorization-code + PKCE flow (`open-pryv.io/components/oauth2/`, open-pryv.io 2.0.0-rc.8) hardens third-party access with mandatory PKCE (S256 only), exact-match redirect-URI validation (single loopback-port carve-out; fragment URIs rejected), curated-only client registration, and short-TTL access tokens paired with single-use rotating refresh tokens. - Credential hand-off: IMPLEMENTED, the shared-secrets endpoints (`open-pryv.io/components/shared-secrets/`) hand a credential to a third party by a one-time random key instead of a URL-embedded token, which would persist in browser history, referrer headers, and server access logs. The key is redeemable exactly once, expires on a mandatory TTL, and Pryv stores only the SHA-256 of its random half, so a database dump cannot reconstruct a live credential. The payload is scrubbed (including from event history) when the secret leaves the pending state: on redemption, on a signature mismatch, and on the first retrieval attempt after the TTL has passed. Expiry is enforced when someone reaches for the secret rather than by a background sweeper, so an expired secret nobody touches again keeps its stored payload until something reaches it or you delete it; schedule that deletion yourself if your retention policy needs a deadline. An optional signature (passphrase or client-computed HMAC whose verifier secret never reaches the server) adds a second factor to the redemption. - Data residency: CONFIGURABLE, multi-hosting puts data where your subjects (or your policy) require, bounding exposure surface. - Ability to ensure ongoing availability + resilience (§1(b)): FACILITATED, a multi-core rqlite cluster in which joining cores register as non-voters by default, so adding or losing a core can never cost the cluster its quorum or take an existing core's control plane offline. Leader-failover HA is an explicit operator topology choice (run ≥3 voters; two voters are rejected as a fragile 2-of-2 quorum); health-checks + audit log round out the ongoing-CIA evidence. - Restoration (§1(c)): IMPLEMENTED, `bin/backup.js --restore` per-user; single-node `peers.json` recovery restores cluster availability after a quorum loss. - Regular testing (§1(d)): FILLED BY EXISTING PRIMITIVES. **Existing evidence (citable today)**: - **Multi-engine CI test matrix**: ~2351 tests on PostgreSQL and SQLite (matched baseline), ~175 test files across `components/*/test/`; runs on every commit + every PR. - **Lint + typecheck gates** (`just lint` + `just typecheck`), neostandard with `{ semi: true }`, `noUnused*` strict. - **Deploy-validation matrix** (an internal release-validation artefact), 8-row scenario matrix exercised on every release. - **Conformance suite** (`lib-js` 168/169 baseline against deployed core), runnable per-deployment for operator-side verification (sample-app proposal queued to package this as a customer- facing "verify your deployment" runbook). - **Supply-chain pipeline** (shipped, open-pryv.io merge `9e2ee7ff`): a CI gate fails the build on high or critical advisories in the runtime npm tree (accepted advisories live in a documented allowlist, not silenced), a CycloneDX SBOM is emitted and Grype-scanned on every CI run, the base image is digest-pinned with the rqlite download checksum-verified, and release images carry a keyless cosign signature plus a SLSA build-provenance attestation. The pinned base image still shows OS-level CVEs in scans (a slimmer-base migration is a tracked follow-up); the claim is detection, gating and attestation, not a CVE-free image. - **Vulnerability disclosure program**: a coordinated disclosure policy ships in `SECURITY.md`: private reporting via GitHub Security Advisories + a `security-dev@` mailbox, a published scope, response-time SLA, safe-harbor language, a 90-day coordinated-disclosure timeline, and GHSA/CVE issuance for confirmed reports. Private vulnerability reporting is enabled on the published repositories, so operators can cite Pryv's VDP + GHSA advisory history as part of their Art.32(1)(d) evidence file. PLANNED (feature, impact low): End-to-end encryption shifts encryption from Configurable infrastructure to a Pryv-managed primitive PLANNED (feature, impact low): Read-only effective-configuration endpoint strengthens the evidence narrative around operator-visible safeguards HDS: facilitated (effort saved: high) (mode: infrastructure) HDS implements transport encryption (TLS), encryption at rest, technical access control and per-user restore, and operates monitoring and alerting as operator. Encryption at rest is now in place in every region via hosting-layer volume encryption (Exoscale default on ch1; AWS EBS on us1, AES-256) — provider-managed keys, verified 2026-06-26. Pseudonymisation is strengthened on two fronts: cross-region PlatformDB identifiers are HMAC-pseudonymised (platform.piiMode=hashed, cutover 2026-06-24), and the platform's access-level alias primitive (`accesses.create {randomAlias:true}` — a random routable alias in place of the username) is deployed on all HDS cores since 2026-07-28. Data residency is facilitated/configurable. Organisational testing and incident procedures remain the controller's. Detail: Access control is enforced at every API call; transport is TLS; per-user restore is available. Event content is encrypted at rest on each core's volume (Exoscale hypervisor-layer encryption on ch1; AWS EBS on us1) — an Art.32(1)(a) measure; keys are provider-managed, so operator-held-key (container-encrypted-volume, CEV_ENABLED) or end-to-end encryption remain stronger options for the "operator cannot read at rest" property. Cross-region PlatformDB PII is HMAC-pseudonymised (platform.piiMode=hashed). HDS as operator runs CI test matrices and a monitored, alert-wired production environment; the controller runs its own organisational testing regime. Evidence: internal:hipaa/policies/encryption, internal:hipaa/policies/transmission-security, internal:hipaa/policies/access-control, internal:hipaa/risk/at-rest-encryption, internal:hipaa/evidence/at-rest-encryption-verification Evidence backing: every internal document cited above has completed approval. PLANNED (platform, impact medium): End-to-end / operator-held-key encryption is queued upstream as the strengthening for the provider-managed-key at-rest residual; claimable on this row only after pryv ships it AND HDS deploys and enables it on all cores. IMPLEMENTER [controller] coverage: documented applies_when: [connects, stores-phi-copy] Assess the residual at-rest-encryption risk, run regular security testing and document your incident procedures. IMPLEMENTER [processor] coverage: documented applies_when: [connects, stores-phi-copy] Evidence your own security measures and the at-rest controls applied at the infrastructure layer. Templates to sign: dpa ## gdpr Art.33 — Notification of personal data breach to the supervisory authority Requirement: The controller must notify the supervisory authority within 72 hours of becoming aware of a breach, unless it is unlikely to pose a risk. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-33 PRYV PLATFORM: facilitated (mode: evidence) Pryv ships a breach-scoping toolchain: `bin/breach-scope.js` turns a compromised accessId + time window into an Art.33 §1(b)-(d) input artefact (subject, methods invoked, streams in scope, record counts, integrity hashes) in one command on the subject's home core. Encryption-at-rest may scope the "unsecured personal data" definition relevant to the notification decision. The risk assessment and the 72-hour process itself are yours to run. Detail: Breach scoping is single-command (shipped in open-pryv.io `0b2874e0`): - `GET /system/accesses/:accessId` admin lookup (PlatformDB reverse-index) resolves a compromised accessId to its user + home core in O(1), revoked accesses included. Existing deployments index pre-existing accesses once per core with `bin/backfill-access-index.js`. - Read audit rows carry `content.recordCount` and `content.scopedStreamIds` (plus `scopedStreamCount` and `recordCountIncomplete`). `scopedStreamIds` is the query's resolved SCOPE: an upper bound on what the access could have exposed, not the streams of the events actually returned. State that nuance in the notification. - `bin/breach-scope.js --access --since [--until ]` walks the audit window on the subject's home core and renders the scoping report (JSON or Markdown): methods histogram, streams in scope, read/mutated/destroyed record counts, time window, integrity hashes. - access version chain → consent state at the moment of access (was processing within authorised scope?). - encryption-at-rest → if the leaked artefact is encrypted operator backup, the data may qualify as "secured" and notification may not be required per Art.33 §1. Honest bounds: the report classifies by stream + method and quantifies by record count; it does not derive event-type data categories (event bodies never enter the audit log); HF/series reads and audit-filter-excluded methods are not visible; the reverse-index is advisory (home-core storage is authoritative). Detection-of-breach itself depends on monitoring + log review you run around the audit data. HDS: facilitated (effort saved: medium) (mode: evidence) The audit log helps scope a breach — which data, which subjects, by which access — and HDS as operator runs the monitoring and incident-response procedure that feeds the 72-hour decision. Since 2026-07-29 that scoping is a deployed platform primitive: `bin/breach-scope.js` emits an Art.33(1)(b-d) report for a compromised access from the audit + access-version data, backed by a cluster-wide access reverse-index (`GET /system/accesses/:accessId`) and scoped-exposure audit fields (`recordCount`, `scopedStreamIds` — the resolved scope, an upper bound on exposure). The notification itself, and the risk-likelihood judgement, are the controller's. At-rest volume encryption (in place since 2026-06-26) narrows the exposure of a leaked at-rest artefact and feeds the risk-likelihood assessment. Detail: `bin/breach-scope.js` resolves a compromised accessId to its owner and window, then reports the accesses that touched the data and the streams in scope — the §33(1)(b) categories/subjects and (b-d) inputs — from the audit log and access-version chain. `scopedStreamIds` records the query's resolved scope (upper bound on what the access could reach), not the events actually returned, so it never understates exposure; `recordCount` counts delivered records. Deployed on all HDS cores 2026-07-29 (open-pryv.io master `d3c9c605`; the access index backfilled per core). HDS runs detection and the operator-side incident procedure; the controller owns the supervisory-authority notification. Evidence: internal:gdpr/procedures/breach-notification-72h, internal:hipaa/procedures/security-incident-response IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy] Run the 72-hour notification process and make the risk determination; the scoping substrate is provided. IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy] Notify the controller without undue delay on becoming aware of a breach. Templates to sign: dpa ## gdpr Art.34 — Communication of a personal data breach to the data subject Requirement: Where a breach is likely to result in high risk, the controller must communicate it to affected data subjects without undue delay. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-34 PRYV PLATFORM: facilitated (mode: evidence) Two-surface split. **Identification** is filled by the audit log + the shipped `bin/breach-scope.js` scoping tool (per-subject roster derivable from the breached access's read/write history); **delivery** is voluntarily missing + operator-owned (Pryv's mail surface is transactional per-recipient, not bulk-send; operators compose with their existing CRM / SMS / push pipeline). The audit-trace bridge that lands per-recipient send-receipts inside Pryv's event chain (satisfying §164.414-equivalent burden-of-proof) uses an operator- authored `compliance/breach-notification/sent-cmc` event pattern. Full treatment in `context/breach-notification-delivery-operator-owned.md`. Encryption-at-rest may scope the high-risk determination (Art.34 §3(a) exemption). Detail: **Identification surface**: derive the affected-subject list from `audit.get` filtered by (`breachedAccessId`, time window). The shipped `bin/breach-scope.js` (open-pryv.io `0b2874e0`) packages this into one command + adds the §164.404(c) content elements (`recordCount` + the `scopedStreamIds` resolved query scope, an upper bound on exposure rather than the streams actually returned) via audit-row extensions. Identification is single-command + audit-defensible. **Delivery surface**: operator-owned by design. Pryv's transactional mail (`mail.send` / `email-templates`) is designed for welcome / password-reset / MFA-code emails, not bulk breach broadcasts. Operators compose: - Identification → the `bin/breach-scope.js` report (JSON output). - Operator's CRM / mail provider (SendGrid / Mailgun / AWS SES / Mandrill) renders Art.34 §2 content elements per recipient + sends with retries + rate-limiting. - Send-receipts captured back into Pryv as `compliance/breach-notification/sent-cmc` events (recipient.userId + email_hash + channel + provider.message_id + notice_version + time) on a dedicated compliance system stream, these become the §164.414-equivalent burden-of-proof artefact. - Operator's incident-response record on `compliance/incidents//*` cross-references the affected.json input + the per-recipient send-receipt event tree. **Why voluntarily missing**: most regulated-market operators already run a CRM / mail / SMS pipeline with established rate-limiting + retry + send-receipt tracking + legal-comms escalation; a Pryv-shipped breach-comm would be redundant. Operators without one need legal/ comms expertise to use Art.34 §2 content + timing well anyway, beyond what a platform-side template can pre- fab. The Art.34 §3 exemptions (encryption-renders- unintelligible / subsequent-measures-eliminate-high-risk / disproportionate-effort) are legal judgements operator- counsel makes. **Multi-jurisdiction nuance**: subjects in different jurisdictions face different timing regimes (GDPR "undue delay" / HIPAA ≤60d / PIPEDA "as soon as feasible" / California ≤45d / Swiss nLPD Art.24 conditional). Operator's runbook derives per-subject timing from `clientData.jurisdiction` on the account. HDS: facilitated (effort saved: low) (mode: evidence) Identification of affected subjects is derivable from the audit log filtered by the breached access and window. Delivery of the communication is the controller's job, composed with its own messaging pipeline; HDS's transactional mail is per-recipient, not a bulk channel. At-rest volume encryption (in place since 2026-06-26) can scope the Art.34(3)(a) exemption for media exposures; a live-system compromise is assessed on its facts. Detail: The affected-subject roster comes from audit queries; the controller's CRM or mail provider renders and sends the Art.34 content per recipient, and send-receipts can be captured back as compliance events. The Art.34(3) exemptions are legal judgements the controller's counsel makes. Evidence: internal:gdpr/procedures/breach-notification-72h, internal:hipaa/procedures/security-incident-response IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy, own-records] Derive the affected-subject roster, render and deliver the communication, and assess the high-risk and exemption questions. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.35 — Data protection impact assessment Requirement: Where processing is likely to result in a high risk, the controller must carry out a data-protection impact assessment before processing. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-35 PRYV PLATFORM: facilitated (mode: evidence) The DPIA is a written assessment artefact; Pryv has no role in producing it. What Pryv supplies as inputs: data-residency primitive lets you state where each subject's data lives; audit + access-version primitives describe the processing-flow technical layer concretely; system-streams isolation gives a defensible "scope of sensitive data" boundary; this matrix itself enumerates the technical-organisational-measures (Art.35 §7(d)) for the deployment. Detail: §7 prescribed content → Pryv-side artefacts feeding each item: - (a) systematic description of processing → audit-log method/path coverage + access purposes from clientData. - (b) necessity / proportionality assessment → the minimum-necessary stream + permission design (cross-link to Art.5 §1(c)). - (c) risk assessment → operator-side artefact; this matrix contributes the technical-control inventory. - (d) measures envisaged to address the risks → see the Art.32 row of this matrix + cross-scope ISO 27001 A.8 control rows. PLANNED (feature, impact medium): Read-only effective-configuration endpoint feeds the DPIA safeguards inventory from live per-core data instead of a hand-written list HDS: facilitated (effort saved: low) (mode: evidence) The DPIA is a written assessment the controller produces; HDS supplies inputs: data-residency facts, audit and access descriptions of the processing flow, system-stream isolation as the sensitive-data boundary, and this matrix as the technical-measures inventory. HDS's own DPIA process is drafted but not yet operating, which it records as an open item; the assessment for an organisation's own processing is that organisation's to run. Detail: The prescribed Art.35(7) content maps onto platform inputs: a systematic description from audit and access purposes, a necessity assessment from the minimum-necessary stream design, and the measures inventory from the Art.32 row. The risk assessment and the DPIA document itself are the controller's. Evidence: internal:gdpr/procedures/dpia PLANNED (procedure, impact low): HDS's own DPIA process is being stood up: the DPIA procedure (baseline) and its record template are drafted in the internal pipeline; the first executed assessment is the tracked remainder. IMPLEMENTER [controller] coverage: documented applies_when: [analytics, secondary-use] Run the DPIA where required, using the platform's technical inputs and this matrix's measures inventory. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.36 — Prior consultation Requirement: The controller must consult the supervisory authority before processing where a DPIA shows a high residual risk absent mitigation. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-36 PRYV PLATFORM: out-of-scope Prior consultation is the controller's procedural interaction with a supervisory authority. No software role; the DPIA artefact under Art. 35 carries the technical evidence the authority may request; Pryv contributes inputs there but not to the consultation itself. HDS: out-of-scope Prior consultation is the controller's procedural interaction with a supervisory authority and has no software role. HDS contributes the technical evidence the authority may request via the DPIA inputs noted at Art.35, but not the consultation itself. IMPLEMENTER [controller] coverage: documented applies_when: [analytics, secondary-use] Consult the supervisory authority where your DPIA indicates an unmitigated high risk. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.37 — Designation of the data protection officer Requirement: The controller and processor must designate a DPO in the cases listed, including large-scale processing of special-category data. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-37 PRYV PLATFORM: out-of-scope DPO designation is an HR / organizational decision. No software role. Where the deployment processes Art. 9 special-category or Art. 10 criminal data on a large scale (likely for healthcare Pryv deployments), the Art. 37(1)(c) trigger applies and a DPO designation is required. HDS: implemented (effort saved: low) HDS has made its processor-side designation: a Data Protection Officer was appointed effective 2026-07-17, recorded in the designated-roles register (disclosed on request; the source register is still moving through internal approval). Healthcare deployments processing special-category data at scale will commonly trigger the Art.37(1)(c) requirement; the controller still makes its own designation. Detail: The designation is an organisational artefact, not a software control. Publishing a public DPO contact point through the service-info convention is the Art.38 follow-up, tracked on that row. Evidence: internal:hipaa/registers/designated-roles Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Determine whether a DPO is required for your processing and designate one where it is. IMPLEMENTER [processor] coverage: documented applies_when: always Designate your own DPO where the Art.37 triggers apply to your processing. Templates to sign: dpa ## gdpr Art.38 — Position of the data protection officer Requirement: The DPO must be involved properly and timely, resourced, independent, and reachable by data subjects. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-38 PRYV PLATFORM: facilitated (mode: storage) DPO independence + reporting structure (§1-§3) is an organizational arrangement; no software role. **§4 DPO contact-point for data subjects IS facilitated** by the existing `serviceInfo.support` URL (returned by `GET /service/info` on every core). Operators publish DPO contact details on the page that `support` points at, the same surface that `app-web-auth3` already renders in its consent UI. Zero extra platform code required. Full convention treatment in `context/service-info-conventions.md`. HDS: facilitated (effort saved: low) (mode: storage) DPO independence and reporting structure are organisational arrangements with no software role. The Art.38(4) data-subject contact point is facilitated by the service-info support URL returned by every core, which consent UIs already render — the controller publishes DPO contact details there at no extra platform cost. Detail: HDS surfaces the support/contact URL platform-wide; the controller populates it with DPO contact details. The DPO's resourcing, independence and direct-reporting position remain organisational arrangements the controller establishes. Evidence: internal:gdpr/procedures/dpia IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Establish the DPO's independence and reporting line and publish the DPO contact point. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.39 — Tasks of the data protection officer Requirement: The DPO must, at minimum, inform and advise, monitor compliance, advise on the DPIA, and cooperate with and be the contact point for the supervisory authority. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-39 PRYV PLATFORM: facilitated (mode: evidence) DPO duties are organizational. Pryv contributes the data sources the DPO uses for "monitoring compliance", the audit log, observability metrics, this matrix's evidence trail. The DPO contact-point obligation per Art.38(4) is covered separately via the `serviceInfo.support` URL convention (see `context/service-info-conventions.md`). Pryv equips the DPO; it doesn't replace them. Detail: Practical DPO-monitoring patterns: - **Audit-log access** for the DPO is currently bound to per-user-scoped permissions; no built-in "cross-account audit reader" personal-token tier exists. Operators granting DPOs platform-wide audit visibility typically use `auth.adminAccessKey` style admin auth, OR run a side-process that exports audit events into the DPO's observability / SIEM stack (Q23 observability-provider primitive, pluggable façade). - **Compliance matrix as evidence trail**: this compliance-matrix repository itself is the structured artefact the DPO references for "what does the platform contribute to each regulatory control?", see how scopes / requirements / pryv_primitives / planned chips / context notes interlink for the auditable claim graph. - **DPIA / breach-scope tooling** the DPO consumes when active: `bin/breach-scope.js` for the breach scoping artefact (shipped), and the future `CONFIG-EFFECTIVE-EXPOSURE` effective-config endpoint for DPIA Section (d). HDS: facilitated (effort saved: low) (mode: evidence) DPO duties are organisational. HDS contributes the data sources the DPO uses to monitor compliance — the audit log, monitoring telemetry, and this matrix's evidence trail — but does not replace the DPO. The contact point is covered via the service-info convention. Detail: Audit-log access for a platform-wide compliance view is operator-mediated (no built-in cross-account audit-reader tier); this matrix itself serves as the structured artefact the DPO references for the platform's contribution to each control. Evidence: internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Resource your DPO to perform these tasks using the platform's audit and monitoring data and this matrix. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.40 — Codes of conduct Requirement: Authorities and bodies are to encourage codes of conduct that help apply the Regulation properly. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-40 PRYV PLATFORM: facilitated (mode: awareness) Codes of conduct are sector- level instruments (drafted by associations of controllers / processors, approved by competent supervisory authority). No software role at the code-drafting layer. When a code applies to your sector, adherence is recorded as one of the Art. 24 / Art. 32 "appropriate measures"; the audit log + this matrix demonstrate the technical-control side of code adherence. HDS: facilitated (effort saved: low) (mode: awareness) Codes of conduct are sector-level instruments with no software role at the drafting layer. Where a code applies to a controller's sector, adherence counts among the Art.24/Art.32 appropriate measures, and the audit log plus this matrix evidence the technical side of adherence. Detail: HDS does not draft or adopt codes on a controller's behalf; it supplies the technical-control evidence a controller can cite when demonstrating adherence to a code it has signed up to. Evidence: internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Adhere to any applicable sector code and cite the platform's technical controls as part of that adherence. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.42 — Certification Requirement: Authorities and bodies are to encourage data-protection certification mechanisms, seals and marks. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-42 PRYV PLATFORM: facilitated (mode: awareness) Certification (e.g., EuroPrivacy seal, GDPR-certified processor schemes) is sector- and jurisdiction-specific. Pryv operators pursuing certification consume this matrix as the technical-control inventory. ISO 27701 + (where applicable) HDS are adjacent certifications already represented in this matrix. HDS: facilitated (effort saved: low) (mode: awareness) Certification is sector- and jurisdiction-specific. A controller pursuing a GDPR certification scheme consumes this matrix as the technical-control inventory; adjacent certifications (e.g. ISO 27701, and HDS hosting certification) reinforce the evidence base. Detail: HDS does not itself confer a GDPR certification; it provides the structured technical-control evidence a controller's certification body will examine. Evidence: internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Pursue any applicable certification using this matrix as your technical-control inventory. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.82 — Right to compensation and liability Requirement: Anyone suffering material or non-material damage from an infringement is entitled to compensation from the controller or processor. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-82 PRYV PLATFORM: facilitated (mode: evidence) Liability + compensation are legal proceedings. Pryv contributes defense evidence: the audit log + access-version chain support the controller / processor in demonstrating compliance with the relevant obligations (or, where compliance failed, in scoping the actual damage). The legal outcome is fact-specific. HDS: facilitated (effort saved: low) (mode: evidence) Liability and compensation are legal proceedings. HDS contributes defence evidence — the audit log and access version chain support demonstrating compliance or, where it failed, scoping the actual damage. The legal outcome is fact-specific. Detail: The audit trail and version chain are the durable evidence a controller or processor relies on in a liability dispute; HDS makes no determination of fault or damage. Evidence: internal:gdpr/registers/records-of-processing IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Rely on the audit and version evidence in any liability dispute; the legal posture is yours. IMPLEMENTER [processor] coverage: documented applies_when: always Maintain your own records to evidence compliance with your processor obligations. Templates to sign: dpa ## gdpr Art.83 — General conditions for imposing administrative fines Requirement: Supervisory authorities must ensure fines are effective, proportionate and dissuasive, up to the prescribed ceilings. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-83 PRYV PLATFORM: out-of-scope Fines are regulator-side. Pryv has no role in fine calculation or imposition. Pryv-side data + this matrix help the controller argue for mitigation under Art. 83(2) factors (degree of cooperation, technical + organisational measures implemented, etc.). HDS: out-of-scope Fines are regulator-side; HDS has no role in their calculation or imposition. The platform's data and this matrix help a controller argue for mitigation under the Art.83(2) factors, such as the technical/organisational measures implemented and the degree of cooperation. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Use the platform's evidence to argue mitigation under the Art.83(2) factors should a fine be considered. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.44 — General principle for transfers Requirement: Any transfer to a third country or international organisation may take place only if the Chapter V conditions are met. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-44 PRYV PLATFORM: facilitated (mode: infrastructure) The Art.44 framework is operational, every Art.45-49 path is conditional. Pryv's data-residency primitive is the technical enforcement layer: when you bind a subject's data to a hosting inside the EU/EEA, no Chapter-V analysis is needed (no transfer happens). When transfer is intentional, the CMC capability flow records the recipient hosting + the legal basis on the originating access's clientData, making Chapter V compliance auditable per transfer rather than per system. Detail: The residency guarantee is **two-tiered**: **Tier 2, Content + audit layer (residency-pinned).** Cores share no event / stream / audit / attachment / access- metadata data with each other. A subject assigned to an EU core has ALL their Tier-2 data exclusively on that EU core's storage. "Transfer" would require a deliberate operator backup-restore between cores (not a runtime primitive). See `context/core-affinity-architecture.md`. **Tier 1, Identification + routing layer (cluster- replicated).** PlatformDB rows (`user-core/`, `user-unique-fields/email`, `dns/`, `access-state/`, `cluster_kv/*`, see `context/cross-border-platformdb-implications.md` for the verified keyspace inventory) replicate cluster-wide via rqlite Raft. In a multi-region cluster, this **is** a continuous cross-border transfer of personal data, an Art.46 mechanism (SCCs / BCRs / etc.) is legally required even though Tier-2 stays put. Mitigation options (filed as backlog or shipped): at-rest encryption of PlatformDB (`PLATFORMDB-AT-REST-ENCRYPTION`), HMAC-pseudonymisation of PII at the PlatformDB layer (`PLATFORMDB-PII-HASHING`, shipped, opt-in via `platform.piiMode: hashed`), tokenisation with per-region mapping table (option C, brainstorm-tier, not yet backlogged). **CMC counterparty nuance**: when an EU subject's stream is shared with a US-based counterparty via CMC, the US client connects directly to the EU core's `apiEndpoint`. The EU Tier-2 data does not replicate to the US core, it's fetched on-demand. From the EU subject's Art.44 perspective this fetch IS a transfer (data crosses borders to reach the reader), so the operator records the recipient + lawful basis on the access's `clientData.transfer_basis` per `context/transfer-basis-convention.md`. The data-at-rest residency is preserved (no Tier-2 copy in the US); only the access path + Tier-1 routing-state crosses. HDS: facilitated (effort saved: medium) (mode: infrastructure) HDS's data-residency option is the technical enforcement layer, and the region is chosen by the individual when they register their vault rather than assigned by an organisation. A vault in the Switzerland region keeps EU and EEA data under an adequacy regime, so no Chapter-V analysis is needed; the US region is an international transfer requiring an Art.45 or Art.46 mechanism. Where a transfer is intentional, the recipient and legal basis are recorded on the access, making compliance auditable per transfer. Detail: Content and audit data stay pinned to the individual's chosen region; a deliberate cross-region move, such as a US counterparty fetching from a Swiss core, is the transfer event. The recipient and transfer basis are recorded on the access, and an organisation making its own onward transfer records the basis in its own transfer records. The legal mechanism itself is a legal artefact, not a platform one. Evidence: internal:gdpr/policies/international-transfers, internal:hipaa/registers/hosting-provider-attestations, internal:hipaa/risk/cross-core-residency-data-flow IMPLEMENTER [controller] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch, third-parties] You do not choose where a vault lives; the individual does, at registration. Ground the transfers you actually make, which are the ones into your own systems and your own processors, and record the basis for each. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.45 — Transfers on the basis of an adequacy decision Requirement: A transfer may take place where the Commission has decided the third country ensures an adequate level of protection. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-45 PRYV PLATFORM: configurable Configure your `auth.hostings` to declare only hostings that match adequate-protection regimes; route subjects to them as per your transfer policy. The per-user `hosting` exposed via `system.users.get` proves residency for auditor questions. Maintenance of which countries currently hold adequacy (EU-US DPF, Switzerland, UK, etc.) is operator-side regulatory tracking. HDS: configurable (effort saved: high) HDS's Switzerland region rests on the EU adequacy decision for Switzerland, so a vault registered there grounds the transfer, or avoids one entirely. The per-user residency is exposed for auditor questions. Tracking which countries currently hold adequacy is the regulatory responsibility of whoever relies on it. Detail: The region is the individual's choice at registration, and the hosting recorded per user proves residency; an organisation can read it but cannot set it. The US region is not an adequacy-based transfer for general EU data and needs Art.46 safeguards instead. Evidence: internal:gdpr/policies/international-transfers, internal:hipaa/registers/hosting-provider-attestations IMPLEMENTER [controller] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch] You cannot route subjects: the individual chooses their vault's region when they register. Track the adequacy landscape for the transfers you actually make, into your own systems and your own processors. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.46 — Transfers subject to appropriate safeguards Requirement: Absent an adequacy decision, a transfer requires appropriate safeguards such as SCCs, BCRs or approved codes. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-46 PRYV PLATFORM: facilitated (mode: storage) Pryv-side artefact: record the §2 mechanism on the transferring access's `clientData.transfer_basis` (structured object per `context/transfer-basis-convention.md`, same pattern as `clientData.lawful_basis` from Art.6 + `clientData. special_category_basis` from Art.9). The Art.30(1)(e) transfers register is then derivable in a single `jq` query against `GET /accesses`. The SCCs / BCRs / approved-code documents themselves remain operator/legal artefacts; Pryv persists the references + the metadata travels with the access version chain. Detail: Three cross-border surfaces in a typical Pryv deployment: 1. **Access-bound transfers** (CMC counterparty fetches, third-party-app reads across jurisdictions). Convention: `access.clientData.transfer_basis` per `context/transfer-basis-convention.md`. Existing primitives carry persistence + versioning + audit trail for free (zero Pryv code change). 2. **Multi-region cluster replication** (Tier 1 of the two-tier residency model, PlatformDB rows for usernames, emails, DNS subdomains, user-core mappings). See `context/cross-border-platformdb-implications.md` for the verified keyspace inventory + the A/B/C mitigation options (at-rest encryption / PII hashing / tokenisation). The strongest compliance posture combines an Art.46 mechanism (SCCs, BCRs, etc.) WITH at-rest encryption (`PLATFORMDB-AT-REST-ENCRYPTION` backlog) AND PII pseudonymisation at the PlatformDB layer (`PLATFORMDB-PII-HASHING`, shipped, opt-in via `platform.piiMode: hashed`). 3. **Subprocessor outbound** (SMTP / SMS / observability vendors). See `context/subprocessor-posture-and-data- flow.md`. **Pryv recommends configuring per-core SMTP endpoints** so the relay can match the core's region / country when residency is a hard requirement, the `services.email.smtp.*` config is per-core, so an EU core routes mail through an EU SMTP relay independently of a US core's relay. Same pattern applies to SMS endpoints. For the §2 mechanism field convention: `mechanism: "art.46.2.c"` for SCCs, `"art.46.2.a"` for legally-binding-instrument-between-public-authorities, `"art.46.2.f"` for approved certification, etc. Or `"art.45"` with an `adequacy_decision` field if relying on an adequacy decision. Full field reference in the convention note. HDS: facilitated (effort saved: low) (mode: storage) A vault registered in the US region is a transfer that needs an Art.46 safeguard, typically standard contractual clauses. HDS records the chosen mechanism on the transferring access clientData so the Art.30 transfers register is derivable. HDS's own upstream instrument for the US hosting layer is still being executed: the AWS HIPAA BAA is in force, while the GDPR DPA plus EU and Swiss standard contractual clauses with the transfer impact assessment are the tracked remainder (see the planned chip). Until those are signed and recorded, US-region transfers rest on the HIPAA instrument alone. The safeguard documents themselves are legal artefacts of whoever concludes them. Detail: The transfer surfaces, which are access-bound counterparty fetches, the region a vault sits in, and subprocessor outbound flows, each carry the mechanism reference on the relevant artefact. HDS persists the references with versioning and audit; whoever makes the transfer concludes the safeguard instrument. Evidence: internal:gdpr/policies/international-transfers, internal:hipaa/registers/subprocessor-register, internal:hipaa/risk/cross-core-residency-data-flow PLANNED (doc, impact high): Execution of the AWS GDPR DPA plus EU/Swiss SCCs with the transfer impact assessment for the US hosting layer is the tracked remediation (the HIPAA BAA is already in force; the crossing is pseudonymised since 2026-06-24, which strengthens the TIA). IMPLEMENTER [controller] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch, third-parties] Conclude SCCs or another Art.46 safeguard for the third-country transfers you make yourself, and record the mechanism. The region the vault sits in is the individual's choice, not a transfer you arrange. Templates to sign: dpa IMPLEMENTER [processor] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch, third-parties] Sign the SCC-bearing DPA and flow equivalent clauses down to any subprocessor. Templates to sign: dpa, subprocessor ## gdpr Art.47 — Binding corporate rules Requirement: A supervisory authority may approve binding corporate rules meeting the prescribed content and safeguard requirements. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-47 PRYV PLATFORM: out-of-scope BCRs are organizational rules approved by a supervisory authority after a formal process. No software contribution, when BCRs are the chosen Art.46 safeguard, the operator records the BCR reference on the transferring access's clientData (per Art.46 pattern); the BCR document itself is the operator's legal artefact. HDS: out-of-scope BCRs are organisational rules approved through a formal supervisory process, with no software contribution. Where BCRs are the chosen Art.46 safeguard, the organisation relying on them records the reference against the transfers it makes, and the BCR document itself is its legal artefact. IMPLEMENTER [controller] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch, third-parties] If relying on BCRs, obtain approval and record the reference against the transfers you make, in your own transfer records. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.48 — Transfers or disclosures not authorised by Union law Requirement: A third-country court or administrative order to transfer or disclose data is recognised or enforceable only on the basis of an international agreement. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-48 PRYV PLATFORM: out-of-scope Resistance to extraterritorial subpoenas is a legal posture, not a software control. Pryv's audit log will record any forced disclosure executed under the access primitive (which is the only way data leaves the system), making the disclosure documentable after the fact. The decision of whether to comply / contest is legal counsel's, not Pryv's. HDS: out-of-scope Resisting extraterritorial orders is a legal posture, not a software control. Because the access primitive is the only path data leaves the system, the audit log documents any forced disclosure after the fact; the decision to comply or contest is the controller's counsel's. IMPLEMENTER [controller] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch] Decide, with counsel, how to respond to any third-country order; the audit log documents any disclosure made. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.49 — Derogations for specific situations Requirement: Absent adequacy or safeguards, a transfer may rest on one of the enumerated derogations, such as explicit consent or contract performance. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-49 PRYV PLATFORM: facilitated (mode: storage) Each Art.49 derogation requires per-instance recording. Pryv pattern: mint a purpose- specific access per derogation invocation with `clientData.transfer_derogation = "art_49_1_a_consent"` etc.; execute the transfer; revoke. The audit trail then anchors the derogation rationale to the specific data movement. HDS: facilitated (effort saved: low) (mode: storage) Each derogation requires per-instance recording. The HDS pattern mints a purpose-specific access tagged with the derogation relied on, executes the transfer, and revokes; the audit trail then anchors the rationale to the specific data movement. Whether a derogation actually applies is the controller's legal judgement. Detail: The derogation tag on the access plus the audit record give a defensible, per-transfer artefact. HDS does not assess the derogation's availability. Evidence: internal:gdpr/policies/international-transfers IMPLEMENTER [controller] coverage: documented applies_when: [transfer-eu-us, transfer-eu-ch] Establish that a derogation applies, record it per transfer, and limit the transfer to that purpose. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## gdpr Art.50 — International cooperation for the protection of personal data Requirement: The Commission and authorities are to develop international cooperation mechanisms for effective enforcement. Anchor: https://compliance.datasafe.dev/gdpr.html#req-art-50 PRYV PLATFORM: out-of-scope International-cooperation development is a regulator-level activity. No software contribution; no implementer obligation arises from this Article alone. HDS: out-of-scope Developing international-cooperation mechanisms is a regulator-level activity with no software contribution and no implementer obligation arising from this Article alone. IMPLEMENTER [controller] coverage: out-of-scope applies_when: always; nature: orientation (not a duty); PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA # HIPAA Breach Notification Rule (hipaa-breach) regulation · US · 45 CFR Part 164 Subpart D (HITECH 2013 Omnibus Final Rule) · regions: us Official text: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D HDS's own position on HIPAA-Breach: - vault: HDS is not-applicable. 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. External assurance: self-assessed. No independent review. The incident and breach procedure has been rehearsed, not tested by a real reportable breach. Evidence: 12 of 13 requirements answered from approved HDS documentation (12 cite internal evidence), as of 2026-09-10. 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. NOTE: 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. Known gaps in HDS's own position: - [medium] No row in this scope has completed review, and the notification procedure has never run against a real incident. ## hipaa-breach 164.400 — Applicability Requirement: Subpart D applies to covered entities, business associates, subcontractors and affiliated entities with respect to unsecured protected health information. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-400 PRYV PLATFORM: facilitated (mode: infrastructure) 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 (effort saved: low) (mode: infrastructure) 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: 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. Evidence: internal:hipaa/risk/at-rest-encryption, internal:hipaa/evidence/at-rest-encryption-verification, internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: integration; nature: orientation (not a duty) Determine which of your data flows on HDS fall inside the unsecured-PHI scope and document that determination in your breach-readiness records. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: integration; nature: orientation (not a duty) Confirm which protections apply to the data you hold and which obligations flow down to your own subcontractors. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.402 — Definitions — breach and unsecured PHI Requirement: 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). Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-402 PRYV PLATFORM: facilitated (mode: evidence) 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. Detail: §402(2) safe-harbor, "unsecured" excludes PHI made unusable through encryption guidance. Pryv default: TLS 1.3 in transit (always); operator-side at-rest encryption (when configured). AES-256-GCM is the at-rest cipher for the Pryv-managed secrets (platform DB), aligning with the NIST SP 800-111 AES guidance, though for ePHI content at rest, the operator-side encryption (LUKS / PG TDE / dm-crypt) is what governs the §402(2) status. §402(1) risk-assessment factors → Pryv data sources: - Nature + extent of PHI involved → audit row → API method + key request fields → infer streams + event types touched. - Unauthorized person → audit row → accessId → access holder. - Whether PHI was actually acquired or merely accessed → audit row → method (read vs. download attachments etc.). - Extent to which risk was mitigated → access version chain (was access revoked? when?), audit on revocation timestamp. HDS: facilitated (effort saved: medium) (mode: evidence) 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. Evidence: internal:hipaa/procedures/breach-risk-assessment, internal:hipaa/risk/at-rest-encryption Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Apply the breach and unsecured-PHI definitions to each incident and record the determination, drawing on HDS-supplied audit evidence. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Run the same definitional analysis for incidents in your custody and preserve the supporting evidence. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.402(1) — Definition of "breach" — four-factor risk assessment Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-402-1 PRYV PLATFORM: facilitated (mode: evidence) 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 (effort saved: high) (mode: evidence) 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. Evidence: internal:hipaa/procedures/breach-risk-assessment Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Perform and document the four-factor risk assessment for each impermissible use or disclosure, using the HDS-supplied audit inputs. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Conduct the same assessment for incidents you discover and share the result with the covered entity. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.402(2) — Definition of "unsecured PHI" — encryption safe harbor Requirement: "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). Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-402-2 PRYV PLATFORM: facilitated (mode: infrastructure) 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). Detail: Practical guidance: pair `letsEncrypt.enabled: true` with operator- side full-disk encryption on every node + encrypted backup archives to maximize §402(2) safe-harbor reach. NIST SP 800-111-equivalent at-rest encryption applies whether the PHI is in the primary engine, an attachment file, or a `bin/backup.js` output. PLANNED (feature, impact low): End-to-end encryption broadens safe-harbor coverage to bulk event data HDS: facilitated (effort saved: low) (mode: infrastructure) 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 every region 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). Evidence: internal:hipaa/risk/at-rest-encryption, internal:hipaa/evidence/at-rest-encryption-verification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Rely on the at-rest safe harbor for media exposures; assess running-system, account or token compromises separately, where it does not apply. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Reflect the media-vs-live-system safe-harbor boundary in your own risk posture and in assurances you give upstream. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.404 — Notification to individuals Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-404 PRYV PLATFORM: facilitated (mode: evidence) 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`. Detail: Per-subject impact query: filter audit rows by (breachedAccessId, timeWindow) → distinct user ids. That's your §164.404 notification list, with evidence. The shipped `bin/breach-scope.js` (open-pryv.io `0b2874e0`) packages this into one command + adds §164.404(c)(1) (`recordCount` per read audit row) + the `scopedStreamIds` resolved query scope. Note: `scopedStreamIds` is an upper bound on exposure (the streams the query could reach), not the streams of the events actually returned, and the report does not derive PHI data categories from it; mapping streams to "types of PHI" stays editorial. §404(c) content elements (description of breach, types of PHI, steps individual should take, what entity is doing, contact info) are editorial; Pryv has no opinion on the wording. Delivery, including rate-limiting + retries + send-receipt tracking, uses the operator's existing notification stack (`context/breach-notification-delivery-operator-owned.md`). HDS: documented (effort saved: low) 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. 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Notify each affected individual within the 60-day window and retain proof of the notifications. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity If your BAA delegates individual notification to you, perform it; otherwise provide the covered entity the information it needs to notify. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.404(b) — Timeliness of notification Requirement: The required individual notification must be provided without unreasonable delay and in no case later than 60 calendar days after discovery of a breach. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-404-b PRYV PLATFORM: facilitated (mode: evidence) 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 (effort saved: low) (mode: evidence) 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Track the discovery date and complete notification within 60 days, documenting the timeline. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Surface discovery to the covered entity promptly so its 60-day clock is not eroded by your delay. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.404(c) — Content of notification Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-404-c PRYV PLATFORM: facilitated (mode: evidence) 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 (effort saved: low) (mode: evidence) 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Author each notice with all required content elements; use HDS audit output to populate the PHI-involved description. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Provide the covered entity the factual elements (PHI involved, dates) it needs to compose the notice. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.404(d) — Methods of individual notification Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-404-d 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 (effort saved: low) 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] coverage: documented applies_when: always; basis: entity Select compliant notification methods, deliver the notices, and retain delivery records including any substitute-notice steps. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.406 — Notification to media Requirement: A breach affecting more than 500 residents of a State or jurisdiction requires notification to prominent media outlets serving that area. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-406 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 (effort saved: low) 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Where the threshold is met, notify prominent media in the affected jurisdiction and retain the records. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.408 — Notification to the Secretary Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-408 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 (effort saved: low) 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity File the required HHS notification on the applicable schedule and keep the submission records. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.410 — Notification by a business associate Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-410 PRYV PLATFORM: facilitated (mode: evidence) 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 (effort saved: medium) (mode: operations) This is the core breach duty of an implementer holding a business-associate role: notify the affected covered entity without unreasonable delay and within 60 days of discovery. HDS holds no such role in the vault, so the duty is not HDS's there. HDS does maintain an approved notification procedure for the separate arrangement in which an organisation places protected health information with it on its own behalf, and the audit log lets whoever carries the duty assemble the required content quickly. Detail: 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: integration On receipt of an HDS breach notice, run your own §164.404/406/408 notification obligations. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: integration Notify the covered entity (or upstream BA) you serve within the 60-day window, using the BAA terms and your own breach procedure. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.412 — Law enforcement delay Requirement: 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). Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-412 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 (effort saved: low) 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. Evidence: internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Document any law-enforcement delay request and the resumption of notification once the stated period ends. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Honor and record any law-enforcement delay communicated to you and inform the covered entity. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-breach 164.414 — Administrative requirements and burden of proof Requirement: 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. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-414 PRYV PLATFORM: facilitated (mode: evidence) "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. PLANNED (feature, impact medium): Chained audit log IS the burden-of-proof artefact (row could shift F:Evidence|Med → F:Evidence|High) HDS: facilitated (effort saved: medium) (mode: evidence) 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. Evidence: internal:hipaa/registers/breach-log, internal:hipaa/procedures/breach-notification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Maintain the documentation that demonstrates notification or a justified no-breach determination, retaining it for the required period. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Keep records demonstrating your own notifications and risk assessments to meet the burden of proof. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA # HIPAA Privacy Rule (hipaa-privacy) regulation · US · 45 CFR Part 164 Subpart E (HITECH 2013 Omnibus Final Rule) · regions: us Official text: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E HDS's own position on HIPAA-Privacy: - vault: HDS is not-applicable. 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. External assurance: self-assessed. No independent Privacy Rule assessment covers HDS. Evidence: 33 of 35 requirements answered from approved HDS documentation (33 cite internal evidence), as of 2026-09-10. 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. NOTE: 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. Known gaps in HDS's own position: - [medium] Thirty-two of thirty-five rows are unreviewed drafts. The positions are stated but not second-read. ## hipaa-privacy 164.502 — Uses and disclosures of PHI — general rules Requirement: A covered entity, or a business associate acting on its behalf, may use or disclose protected health information only as permitted or required by the Privacy Rule. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-502 PRYV PLATFORM: facilitated (mode: primitive) Pryv's permission model is the technical enforcement layer for Article 502: an app or counterparty can only read or write streams its access permits. The "permitted or required by the Privacy Rule" determination, which use cases are TPO, when authorization is required, what minimum-necessary means in your workflow, is your programmatic decision; Pryv enforces whatever scope you grant. Detail: Workforce, apps, and counterparties act on PHI only by holding an access whose `permissions[]` allows the specific stream + level. Disclosures to third parties (via shared accesses or CMC capability flows) inherit the same enforcement model. The audit log makes every use / disclosure attributable to a specific access at a specific time, which is the substrate for §164.528 accounting. HDS: facilitated (effort saved: medium) (mode: primitive) On top of Pryv's permission model, HDS operates the platform that enforces it. HDS is not a business associate in the vault: it holds data for the individual, who decides who may see it, so there is no covered entity whose instructions bound its uses. What bounds them is the permission the individual granted. The substantive determination of which uses are permitted remains the covered entity's wherever one is party to the relationship. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Decide which uses and disclosures are permitted under the Privacy Rule and configure access scopes accordingly. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Use or disclose PHI only as your BAA and the covered entity's instructions permit. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.506 — Uses and disclosures for treatment, payment, healthcare operations (TPO) Requirement: Use and disclosure of PHI is permitted for the entity's own treatment, payment and healthcare operations, and under defined conditions for another entity's TPO. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-506 PRYV PLATFORM: facilitated (mode: storage) TPO is the largest category of permitted uses. Pryv lets you mint accesses tagged with the TPO purpose in `clientData` (e.g., `purpose: "treatment"`); the permission model enforces the scope. The TPO-vs-not classification of any specific workflow is your programmatic judgement; Pryv carries it forward into the audit trail. Detail: A common pattern: separate accesses per purpose (one "treatment-app" access; one "billing-app" access; one "ops-analytics" access), each independently revocable and auditable. `access.clientData.purpose` makes the classification an artefact rather than a verbal claim. HDS: facilitated (effort saved: medium) (mode: storage) HDS provides the means to mint per-purpose accesses tagged with the TPO purpose, each independently revocable and auditable. The classification of any given workflow as TPO is the covered entity's judgement, which HDS carries forward into the audit trail. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [analytics]; basis: entity Classify your workflows as TPO or not and provision purpose-tagged accesses accordingly. IMPLEMENTER [business-associate] coverage: documented applies_when: [analytics]; basis: entity Act on TPO data only within the scope your BAA permits. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.508 — Uses and disclosures requiring authorization Requirement: Uses and disclosures not otherwise permitted require a written authorization from the individual that meets defined content requirements. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-508 PRYV PLATFORM: implemented The authorization Pryv mints when your subject grants an access IS the §164.508 authorization record, versioned, immutable per version, with the granted scope (permissions) and the authorization text (clientData or a `consent/request-cmc` event) inseparable. Withdrawal is a single API call. For cross-account / cross-entity authorizations, the CMC plugin carries the negotiation state. Detail: Section 508(c) elements (description, identification, signature equivalent, expiration, right to revoke, etc.) map naturally to access + clientData fields: - description of information disclosed → `permissions[]` - description of authorized recipients → access type + counterparty (CMC pair) - signature equivalent → the act of granting the access through the auth flow (auditable) - expiration → `access.expires` - right to revoke → `accesses.delete` + audit row at revocation - re-disclosure statement → `clientData.redisclosure_notice` Implementer responsibility: ensure the consent UX presents the §508(c) elements at the grant moment. HDS: facilitated (effort saved: high) (mode: primitive) HDS exposes consent primitives (the @pryv/cmc consent flow and access grant) so the authorization captured when an individual grants an access is a versioned, immutable record binding the granted scope to the authorization text. Withdrawal is a single API call. Detail: 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. Evidence: internal:hipaa/policies/authorizations Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [analytics, secondary-use]; basis: entity Ensure your consent surface presents all §508(c) authorization elements and retains the authorization record. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You grant and revoke authorizations through the consent flow; each act is recorded. IMPLEMENTER [business-associate] coverage: documented applies_when: [analytics, secondary-use]; basis: entity Honour and record authorizations as instructed by the covered entity. Templates to sign: baa ## hipaa-privacy 164.510 — Uses and disclosures requiring opportunity to agree or object Requirement: Disclosures to family or friends, or for facility-directory purposes, may proceed if the individual is given the opportunity to agree or object and no objection is reasonably inferred. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-510 PRYV PLATFORM: facilitated (mode: storage) The opportunity-to-agree-or- object construct is operational. Pryv lets you record the offered choice and the individual's response as durable artefacts (clientData on the relevant access, or a `consent/notice-cmc` / custom event), so the §164.510 reasonable-inference becomes a record rather than recollection. HDS: facilitated (effort saved: low) (mode: storage) HDS provides durable storage for the offered choice and the individual's response as client-data on the relevant access or as a consent event, so the reasonable-inference standard rests on a record rather than recollection. The operational offer itself is the covered entity's. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Offer the opportunity to agree or object and record the individual's response. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.512 — Uses and disclosures for which authorization or opportunity is not required Requirement: Twelve categories of disclosures are permitted without authorization (public health, law enforcement and others), each subject to specific conditions. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-512 PRYV PLATFORM: facilitated (mode: storage) Section 512 disclosures are operationally driven by the circumstances (subpoena, public- health request, etc.). Pryv's contribution is durability: every such disclosure must still go through an access, and the audit log captures it. Recording the §512 category and rationale in `access.clientData.legal_basis` makes the disclosure justification recoverable later. Detail: Recommended pattern: mint a purpose-specific access per §512 invocation (`clientData.disclosure_category: "law_enforcement"`, `clientData.statute: "..."` etc.), execute the disclosure, and revoke the access. The audit trail then shows the full lifecycle attached to the legal-basis claim. HDS: facilitated (effort saved: low) (mode: storage) HDS contributes durability: every §164.512 disclosure still rides on an access and is captured in the audit log, and the §512 category and rationale can be recorded against the access. Whether a disclosure qualifies is the covered entity's legal determination. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [secondary-use]; basis: entity Determine whether each disclosure qualifies under §512 and record its category and statutory basis. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.514(a) — De-identification of PHI Requirement: PHI de-identified by the Safe Harbor method or by Expert Determination is no longer subject to the Privacy Rule. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-514-a PRYV PLATFORM: facilitated (mode: storage) Pryv stores whatever event content you write; de-identification is a transformation you perform on the data before storage (or before disclosure). Custom event types + the per-stream design let you keep an identified and a de-identified copy under separate permission scopes, simplifying §514(a) workflows. Detail: A typical pattern: identified events on a `clinical/*` stream tree with restricted access; a parallel `research/*` stream tree holding de-identified projections, accessible to a broader analyst group. The de-identification logic itself (e.g., Safe Harbor's 18-identifier list) is your application code; Pryv stores the output. HDS: facilitated (effort saved: low) (mode: storage) HDS stores whatever event content is written and lets identified and de-identified copies sit under separate permission scopes, simplifying §514(a) workflows. The de-identification determination and transformation are the covered entity's. Detail: 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. Evidence: internal:hipaa/policies/de-identification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [analytics, secondary-use]; basis: entity Choose the de-identification method, perform the transformation, and retain the determination record. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.514(d) — Minimum necessary use, disclosure and requests Requirement: Reasonable efforts must be made to limit PHI to the minimum necessary to accomplish the intended purpose. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-514-d PRYV PLATFORM: implemented Per-stream permissions are the minimum-necessary primitive: each access carries only the streams + levels needed for its purpose, so by construction the holder cannot see more PHI than granted. Your stream layout + permission-design choices determine the granularity at which "minimum necessary" can be enforced technically. Detail: Practical guidance: - Design stream topology so distinct purposes live on distinct subtrees (treatment / billing / research / ops). - Mint per-purpose accesses with `permissions[]` pointing at the smallest necessary subtree. - Avoid blanket `*` permissions except for personal-token / admin roles where unrestricted access is the stated need. HDS: facilitated (effort saved: high) (mode: primitive) Per-stream, per-level access tokens are the minimum-necessary primitive HDS exposes: each access carries only the streams and levels its purpose needs, so by construction the holder cannot see more PHI than granted. The granularity of "minimum necessary" follows the covered entity's stream and permission design. Detail: 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. Evidence: internal:hipaa/policies/minimum-necessary, internal:hipaa/evidence/monitoring-telemetry-no-phi Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects]; basis: integration Design stream topology and permission scopes so each access is limited to the minimum necessary, and document the rationale. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects]; basis: integration Request only the minimum-necessary scope for your processing. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.520 — Notice of privacy practices Requirement: A notice must be provided that adequately describes the entity's uses and disclosures of PHI and the individual's rights. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-520 PRYV PLATFORM: facilitated (mode: storage) The notice itself is your editorial content. Pryv preserves the notice text shown to each subject, typically on `access.clientData.privacy_notice` or as a dedicated event, so the same words presented are recoverable per subject per time. The customer-facing `app-web-auth3` template is the surface where the notice typically appears. HDS: facilitated (effort saved: medium) (mode: storage) This section reaches covered entities, and HDS issues no notice of privacy practices under it. What the platform supplies is preservation: the notice text shown to each individual is stored on the relevant access client-data or as a dedicated event, so the exact words presented are recoverable per individual and per time. The notice content stays the covered entity's editorial responsibility. Detail: 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. Evidence: internal:hipaa/policies/notice-of-privacy-practices Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Author and maintain your notice of privacy practices and present it to individuals as required. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.522 — Right to request restriction; confidential communications Requirement: An individual may request restrictions on uses and disclosures and may request to receive confidential communications by alternative means or at alternative locations. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-522 PRYV PLATFORM: configurable A granted restriction is a scope-down on the relevant access (`accesses.update` to narrower permissions) or a revocation (`accesses.delete`). The access-version chain proves what state was in force before the restriction and from when it applies. Confidential-communications choices (alternate address, phone) live in `account.clientData` or a dedicated event. Detail: Note that §522(a)(1)(vi) (post-HITECH) made restrictions on disclosures to a health plan for out-of-pocket-paid services mandatory on request. The Pryv pattern is the same, mint / narrow the access tied to the health-plan workflow, but you must apply it without operational discretion when this specific condition is met. HDS: configurable (effort saved: medium) On this platform a restriction is usually the individual's own act: they narrow or revoke the relevant access themselves, with immediate effect, and the access version chain proves what state was in force before and from when. Where an individual asks HDS to restrict their own data instead, HDS sends written instructions rather than reaching into the account, because the individual remains the decision-maker. Confidential-communication preferences are stored as account client-data or a dedicated event. Detail: 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. Evidence: internal:hipaa/procedures/restriction-requests Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: integration Evaluate restriction and confidential-communication requests and apply the corresponding access changes. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You request restrictions and alternative-communication preferences, which are recorded against your account. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; basis: integration; PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.524 — Right of access by the individual Requirement: An individual has the right to inspect and obtain a copy of their PHI in a designated record set, in the form and format requested if readily producible. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-524 PRYV PLATFORM: implemented Your subject, holding a personal token, reads everything via the standard Pryv API, events, streams, accesses (with history), audit records, attachments, in the canonical event-type schemas. Wrap that in a subject-portal app and you have §164.524 covered end-to-end. The 30-day response timeline is your process target, not a software latency. Detail: Form-and-format: events return as canonical JSON validated against `data-types` schemas, structured, machine-readable, and arbitrary JSON-consumer-friendly. Attachments download in their stored MIME-type. If a subject requests a specific format Pryv doesn't natively produce (e.g., CDA C-CDA), your portal layer transforms. HDS: implemented (effort saved: high) Pryv is user-centric: the individual owns their data and, holding a personal token, reads everything through the standard API — events, streams, accesses with history, audit records and attachments. HDS operates this access capability end-to-end across every region. Detail: 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. Evidence: internal:hipaa/procedures/individual-right-of-access Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You access and export your own PHI directly through the standard API or a subject portal built on it. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Run the access-request process and meet the response timeline; provide any requested non-native export format. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Make PHI available to the covered entity to satisfy access requests. Templates to sign: baa ## hipaa-privacy 164.526 — Right to amend Requirement: An individual has the right to have a covered entity amend PHI or a record about the individual in a designated record set. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-526 PRYV PLATFORM: implemented `events.update` is the amendment primitive; event versioning preserves the prior content so the amendment trail is auditable. The §164.526 process (request → decision → action → notice) is yours to run; the technical record-keeping is shipped. Detail: For denied amendments where the individual files a statement of disagreement (§526(d)), store the statement as a separate event on a designated-record-set stream linked back to the original via `clientData.amends_event_id`, so the disagreement travels with the data on subsequent disclosures. HDS: facilitated (effort saved: high) (mode: evidence) HDS exposes event update as the amendment primitive, with event versioning preserving prior content so the amendment trail is auditable. The §164.526 process of request, decision, action and notice is the covered entity's to run. Detail: 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. Evidence: internal:hipaa/procedures/amendment-requests Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Run the amendment request, decision and notice process and record accepted amendments and statements of disagreement. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You request amendments; accepted changes and any disagreement statement are preserved with version history. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; basis: entity; PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.528 — Accounting of disclosures Requirement: An individual has the right to an accounting of disclosures of their PHI made in the six years prior to the request, with specified exceptions. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-528 PRYV PLATFORM: implemented Pryv's audit log is the §164.528 substrate: every API method call attributed to an access (with version) is recorded. Filtering by access category, TPO accesses, §164.512 disclosures, etc., lets you derive the §164.528-eligible subset (which excludes TPO). Six-year retention of the audit log is your operator-side configuration. Detail: The accounting must include: date, recipient, brief description of PHI disclosed, purpose. Each field has a Pryv source: - date → audit row timestamp - recipient → access holder (`access.id`) or counterparty (for shared / CMC accesses) - description → API method + URL query/path params recorded in audit. **The audit log does NOT capture the request body**, so the description is "what was disclosed" at the API-shape level (e.g., `events.get` on a given stream), not the per-event content, sufficient under §164.528 and favourable for data minimisation (the audit row carries no residual PHI when the underlying event is later erased). See `docs/pryv-primitives.md` audit entry for the full capture catalogue. - purpose → `access.clientData.purpose` recorded at grant time Pre-computing per-subject accounting reports periodically (and storing them on a dedicated stream) is a useful operational pattern for fast response to requests. HDS: facilitated (effort saved: high) (mode: evidence) The audit log is the §164.528 substrate: every API method call attributed to an access and version is recorded, and filtering by access category lets the covered entity derive the accountable subset. Six-year retention of the audit log is an HDS-operated configuration on every region. Detail: 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. Evidence: internal:hipaa/procedures/accounting-of-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: integration Compile and deliver the accounting, applying the §164.528 exceptions and your retention policy. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You request an accounting; the audit log provides the underlying disclosure record. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: integration Provide the covered entity with the disclosure records you hold. Templates to sign: baa ## hipaa-privacy 164.530(a) — Privacy officer / contact person Requirement: A covered entity must designate a privacy official and a contact person responsible for receiving complaints. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-a PRYV PLATFORM: facilitated (mode: evidence) Designation is organizational. Pryv's contribution is indirect: the audit log gives the privacy official a concrete artifact to review when investigating complaints or auditing internal use. HDS: implemented (effort saved: low) HDS has designated its own Privacy Official: a distinct holder from the Security Official, appointed by the CEO effective 2026-07-15 and recorded in the designated-roles register (disclosed on request; the source documents are still moving through internal approval). That designation is HDS's own governance choice, not a duty it carries under this section, which reaches covered entities. The audit log gives that official a concrete artefact to review when investigating complaints or internal use. The covered entity's own privacy-official designation remains its organizational decision. Detail: 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. Evidence: internal:hipaa/policies/privacy-program-governance, internal:hipaa/registers/designated-roles Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Designate and document your privacy official and complaint contact. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(b) — Training Requirement: A covered entity must train all workforce members on its privacy policies and procedures. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-b PRYV PLATFORM: facilitated (mode: evidence) Training itself is your programme. Pryv's contribution to operationalizing it: the audit log + observability data make training-effectiveness measurable (e.g., does role X exercise access patterns matching policy after training?). The training content + record-keeping are yours. HDS: documented (effort saved: low) Workforce privacy training is the covered entity's programme. HDS trains its own workforce on its privacy and security policies and retains the training records, as its own governance rather than as a duty it carries under this section; the customer's programme is out of HDS's scope. Detail: 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. Evidence: internal:hipaa/procedures/workforce-training Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Train your workforce on your privacy policies and retain the training records. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Train your own workforce on safeguarding PHI under your BAA. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(c) — Safeguards Requirement: A covered entity must have appropriate administrative, technical and physical safeguards to protect the privacy of PHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-c PRYV PLATFORM: facilitated (mode: awareness) Section 530(c) is the Privacy Rule's pointer to the Security Rule and to physical / administrative safeguards. See the HIPAA-Security rows for the technical safeguards Pryv contributes; §164.310 (Physical) for the operator's hosting environment. Together those rows constitute the §530(c) answer for this Pryv deployment. HDS: facilitated (effort saved: medium) (mode: infrastructure) Section 530(c) points to the Security Rule and to physical and administrative safeguards. HDS supplies the technical and hosting safeguards documented in the HIPAA-Security scope — access control, audit, encryption in transit and at rest, regional residency — that partly answer §530(c) for an HDS deployment. Detail: 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. Evidence: internal:hipaa/policies/privacy-safeguards Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Maintain administrative safeguards and document how the technical and physical safeguards meet §530(c). IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(f) — Mitigation Requirement: A covered entity must mitigate, to the extent practicable, any harmful effect of a use or disclosure in violation of its policies or the Privacy Rule. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-f PRYV PLATFORM: facilitated (mode: evidence) Audit log + access version chain let you scope what was disclosed to whom and when, the first step in any mitigation. `bin/backup.js --restore` is available if mitigation involves rolling back data state; `accesses.delete` is the primitive to revoke access from the offending counterparty. HDS: facilitated (effort saved: medium) (mode: evidence) Audit log and access version chain let the covered entity scope what was disclosed, to whom and when — the first step in any mitigation. HDS provides access revocation and operates backup and restore should mitigation require rolling back data state. Detail: 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. Evidence: internal:hipaa/procedures/incident-mitigation Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Investigate violations, decide and execute mitigation, and run any required notifications. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Report incidents to the covered entity and assist mitigation per your BAA. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.502(b) — Minimum necessary uses, disclosures and requests Requirement: Reasonable efforts must be made to limit PHI to the minimum necessary, subject to enumerated exceptions including treatment disclosures, disclosures to the individual, authorized disclosures and disclosures required by law. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-502-b PRYV PLATFORM: implemented Same primitive mapping as §164.514(d) minimum-necessary: per- stream permissions are the technical control; the holder cannot see more PHI than the granted scope permits. §502(b)(2) exceptions are programmatic, the implementer leaves those accesses unscoped per the exception's permission, and the audit log records the broader access for accountability. HDS: facilitated (effort saved: high) (mode: primitive) Per-stream permissions are the same minimum-necessary control as §164.514(d): the holder cannot see more PHI than the granted scope permits. The §502(b)(2) exceptions are programmatic, and the audit log records any broader access for accountability. Detail: 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. Evidence: internal:hipaa/policies/minimum-necessary, internal:hipaa/evidence/monitoring-telemetry-no-phi Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, analytics]; basis: integration Apply minimum-necessary scoping and document where exceptions are invoked. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, analytics]; basis: integration Limit your requests and uses of PHI to the minimum necessary. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.502(e)(1) — Disclosures to business associates Requirement: A covered entity may disclose PHI to a business associate, and allow it to create, receive, maintain or transmit PHI on its behalf, only with satisfactory assurances — typically a written BAA — that the business associate will appropriately safeguard the information. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-502-e-1 PRYV PLATFORM: facilitated (mode: storage) The technical disclosure is mediated by the access primitive, mint a BA-specific access with `clientData.role = "business_associate"` + `clientData.baa_id = ""`, scoped to the subjects / streams covered by the BAA. Cross-platform BA arrangements (where the BA runs their own Pryv) inherit the CMC capability pattern for cross- account flow. HDS: facilitated (effort saved: medium) (mode: storage) HDS offers a Business Associate Agreement template and the technical disclosure mechanism: a BA-specific access tagged with its role and contract reference, scoped to the subjects and streams the agreement covers. HDS signs BAAs downstream, with the subcontractors that host the data. It holds no upstream agreement: no covered entity or partner customer has engaged HDS as its business associate, and in the vault none arises, because access flows from the individual's own consent. Detail: 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. Evidence: internal:hipaa/registers/baa-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [third-parties]; basis: entity Execute a BAA with each business associate before disclosing PHI and scope their access to what the BAA covers. Templates to sign: baa IMPLEMENTER [business-associate] coverage: documented applies_when: [third-parties]; basis: entity Sign the BAA and flow obligations down to any subcontractors. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(d) — Complaints to the covered entity Requirement: A covered entity must provide a process for individuals to complain about its policies, procedures or compliance, and must document complaints received and their disposition. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-d PRYV PLATFORM: facilitated (mode: storage) A complaint-intake workflow stores each complaint as an event on a designated `complaints/*` stream with `clientData.disposition` tracking outcome. The audit log captures the timestamp + actor on each disposition update, making the §530(d)(2) documentation requirement an automatic byproduct of normal record-keeping. HDS: facilitated (effort saved: medium) (mode: storage) HDS provides the means to store each complaint as an event on a dedicated stream with a disposition field, and the audit log captures the timestamp and actor on each disposition update. The complaint-handling process is the covered entity's. Detail: 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. Evidence: internal:hipaa/procedures/complaint-handling Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Operate the complaint process and document complaints and their dispositions. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(e) — Sanctions Requirement: A covered entity must have and apply appropriate sanctions against workforce members who fail to comply with its privacy policies and procedures. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-e PRYV PLATFORM: out-of-scope Sanctions are an HR / disciplinary process. No software role at the sanction-decision layer; the audit log gives the underlying evidence ("did this person actually access X?") that HR processes evaluate. HDS: documented (effort saved: low) Sanctions are an HR and disciplinary process with no software role at the decision layer. HDS maintains a workforce sanction policy of its own, adopted by the CEO on 2026-07-15 with a graduated scale in force; the audit log supplies the underlying evidence a disciplinary process would evaluate. A covered entity's own sanction programme remains its own. Detail: 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. Evidence: internal:hipaa/policies/workforce-sanctions Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Maintain and apply your workforce sanction policy and document enforcement. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Maintain sanctions for your own workforce under your BAA. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(g) — Refraining from intimidating and retaliatory acts Requirement: A covered entity may not intimidate, threaten, coerce, discriminate against or retaliate against an individual for exercising any right under the Privacy Rule. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-g PRYV PLATFORM: out-of-scope Anti-retaliation is an organizational policy + culture commitment; no software role. HDS: out-of-scope Anti-retaliation is an organizational policy and culture commitment with no software role. It rests entirely with the covered entity's programme. Detail: HDS provides no technical control bearing on this requirement; it is a conduct obligation of the covered entity. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Maintain and enforce an anti-retaliation policy. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.530(i) — Policies and procedures Requirement: A covered entity must implement policies and procedures designed to comply with the standards and implementation specifications of the Privacy Rule. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-530-i PRYV PLATFORM: facilitated (mode: storage) Same pattern as HIPAA- Security §164.316(a): policies-as-data on a `compliance/policies/*` stream get versioning + retention + audit. The drafting + approval + review-cycle procedure is the privacy officer's. Cross-link to §164.316(a) preserves the Security Rule's parallel obligation. HDS: facilitated (effort saved: medium) (mode: storage) As with the Security Rule's documentation requirement, HDS provides the means to hold policies as versioned, retained, audited data on a dedicated stream. The drafting, approval and review cycle is the privacy officer's. HDS maintains its own privacy policies as a matter of its own governance rather than as a duty this section places on it, since §164.530 reaches covered entities. Detail: 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. Evidence: internal:hipaa/policies/privacy-policy-management Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Author, approve and periodically review your privacy policies and procedures. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Maintain policies and procedures for safeguarding PHI under your BAA. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.510(b) — Disclosures for involvement in care and for notification purposes Requirement: A covered entity may disclose to a family member, relative, close friend or other person identified by the individual PHI directly relevant to that person's involvement in the individual's care or payment for care. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-510-b PRYV PLATFORM: facilitated (mode: storage) The §510(b) "directly relevant" determination + relationship verification are clinical-workflow concerns. Pryv pattern: mint a time-bounded access for the involved person with permissions narrowed to "directly relevant" streams + `clientData.relationship` capturing the §510(b)(1) basis (family member name, role, individual's opportunity-to-object record). HDS: facilitated (effort saved: medium) (mode: storage) HDS supports minting a time-bounded access for the involved person, with permissions narrowed to the directly-relevant streams and client-data capturing the relationship and the §510(b) basis. The directly-relevant determination and relationship verification are clinical-workflow concerns of the covered entity. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Determine directly-relevant scope, verify the relationship, and record the disclosure basis. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You identify the persons involved in your care and may object. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; basis: entity; PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.512(b) — Uses and disclosures for public-health activities Requirement: A covered entity may disclose PHI for public-health activities to authorities authorized by law to collect or receive it, including disease and injury reporting, vital-event reporting and public-health surveillance. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-512-b PRYV PLATFORM: facilitated (mode: storage) Public-health-authority recipient is recorded on the access's `clientData.recipient_authority` + `clientData.statute` for the §512(b) statutory basis. Audit log anchors the disclosure to a specific timestamp + event range. The "authorized by law" determination is the covered entity's legal judgement. HDS: facilitated (effort saved: low) (mode: storage) HDS lets the recipient authority and statutory basis be recorded on the access, and the audit log anchors the disclosure to a timestamp and event range. The authorized-by-law determination is the covered entity's legal judgement. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Confirm the public-health authority's legal basis and record the disclosure. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.512(f) — Uses and disclosures for law-enforcement purposes Requirement: A covered entity may disclose PHI for law-enforcement purposes under specific conditions, such as court order or warrant, administrative request, identification and location, victim of crime, or decedent. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-512-f PRYV PLATFORM: facilitated (mode: storage) §512(f) categories drive vocabulary for `clientData.law_enforcement_basis` (e.g., `"f_1_i_court_order"`, `"f_2_ii_subpoena"`, `"f_4_victim"`). Per-instance disclosure access minted + revoked; audit log preserves the chain. The decision of whether the request qualifies under §512(f) is legal counsel's, not Pryv's. HDS: facilitated (effort saved: low) (mode: storage) HDS supports recording the §512(f) category as the law-enforcement basis on a per-instance access that is minted and revoked around the disclosure, with the audit log preserving the chain. Whether the request qualifies under §512(f) is legal counsel's decision. Detail: 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. Evidence: internal:hipaa/procedures/law-enforcement-requests Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Evaluate law-enforcement requests against §512(f) conditions and record the basis. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.524(b) — Right of access — requests and responses Requirement: A covered entity may require written access requests within reasonable limits and must act within 30 days, with one 30-day extension permitted on written notice. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-524-b PRYV PLATFORM: facilitated (mode: storage) Request-intake workflow stores each request as an event on a designated `access-requests/*` stream with `clientData.due_by` computed from receipt timestamp. The 30/30-day operational cadence is the covered entity's process; once the response is ready, the individual exercises §524 directly via the standard Pryv API (see the §164.524 parent row). HDS: facilitated (effort saved: medium) (mode: storage) HDS supports storing each access request as an event on a dedicated stream with a computed due date, so the 30/30-day cadence is trackable. The operational cadence and decision remain the covered entity's; for individuals who can self-authenticate, the app-portability self-service tool bypasses the 30-day clock entirely (the individual obtains the data immediately, without a written-request intake). Detail: 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. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, internal:hipaa/procedures/individual-right-of-access Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Operate the request intake and meet the §524(b) response timeline. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You submit access requests, which are tracked to a due date. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; basis: entity; PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.524(c) — Right of access — provision of access Requirement: A covered entity must provide access in the form and format requested if readily producible, otherwise in readable hard copy or another agreed form, and must provide a summary if the individual agrees in advance. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-524-c PRYV PLATFORM: implemented The Pryv API delivers events in canonical JSON (data-types schemas), "readily producible" in the §524(c) sense. Implementer's portal can transform to PDF / printed format where requested. Summaries are application-layer constructions from the same source events. HDS: implemented (effort saved: high) The HDS-operated API delivers events in canonical JSON validated against the data-type schemas — readily producible in the §524(c) sense — across every region. The app-portability self-service web app gives individuals a one-click ZIP download of their full PHI dump; transformation to PDF or print and summary construction remain application-layer work on the same source events. Detail: 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. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, doc:https://github.com/healthdatasafe/app-portability, internal:hipaa/procedures/individual-right-of-access Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You obtain your PHI in canonical JSON or a format your portal produces. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Provide requested formats and summaries and agree applicable fees in advance. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; basis: entity; PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.502(g) — Personal representatives Requirement: A covered entity must treat a personal representative as the individual for uses and disclosures of PHI, subject to exceptions for abuse, neglect or endangerment concerns. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-502-g PRYV PLATFORM: facilitated (mode: storage) Pryv pattern: the personal representative holds an `app` or `shared` access to the subject's data with full scope (the effective "treat as individual" technical permission). The access's `clientData.representative_relationship` + `clientData.legal_basis` capture the relationship; the revocation-by-exception pattern is `accesses.update` to narrow / `accesses.delete` to remove. The "abuse / neglect / endangerment" determination is clinical / legal judgement. HDS: facilitated (effort saved: low) (mode: storage) HDS supports the representative holding an access to the individual's data with the appropriate scope — the technical "treat as the individual" permission — with the relationship and legal basis recorded as client-data. The abuse, neglect and endangerment exceptions are clinical and legal judgements of the covered entity. Detail: 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. Evidence: internal:hipaa/policies/personal-representatives Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Verify representative status, grant appropriate access, and apply exceptions where warranted. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) A verified personal representative may act on your behalf with recorded basis. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; basis: entity; PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.512(a) — Uses and disclosures required by law Requirement: A covered entity may use or disclose PHI to the extent required by law, limited to the relevant requirements of that law. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-512-a PRYV PLATFORM: facilitated (mode: storage) "Required by law" disclosures still ride on accesses; record the statutory basis in `clientData.statute` so the audit chain ties the disclosure to the legal authority. The compliance burden of the cited law is separate. HDS: facilitated (effort saved: low) (mode: storage) Required-by-law disclosures still ride on accesses, and HDS lets the statutory basis be recorded so the audit chain ties the disclosure to its legal authority. The compliance burden of the cited law is the covered entity's. Detail: 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. Evidence: internal:hipaa/policies/uses-and-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Confirm the legal requirement, limit the disclosure to it, and record the basis. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Disclose as required by law and notify the covered entity per your BAA. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.514(b) — De-identification — implementation specifications Requirement: De-identification may use Expert Determination that re-identification risk is very small, or Safe Harbor removal of the 18 enumerated identifiers with no actual knowledge of residual re-identifiability. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-514-b PRYV PLATFORM: out-of-scope Choice of method + execution are app-side. Pryv stores the output of either method as ordinary events on the de-identified streams. HDS: documented (effort saved: low) The choice of method and its execution are application-side decisions of the covered entity. HDS stores the output of either method as ordinary events on the de-identified streams and provides no de-identification determination of its own. Detail: HDS documents that de-identification is the covered entity's responsibility; the platform simply persists whatever events the implementer's de-identification process produces. Evidence: internal:hipaa/policies/de-identification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [analytics, secondary-use]; basis: entity Select and execute Expert Determination or Safe Harbor and retain the documentation. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.514(c) — De-identification — re-identification Requirement: A covered entity may assign a re-identification code to de-identified information, provided the code is not derived from information about the individual and is not used or disclosed for any other purpose. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-514-c PRYV PLATFORM: facilitated (mode: primitive) `accesses.create {randomAlias:true}` provides the re-identification code directly: it mints a platform-unique `r-XXXXXXXX` alias that is random by construction (does not encode PHI), so it satisfies §514(c)(1)(ii) out of the box. The platform holds the alias-to-user mapping and the aliased access exposes only the alias, the covered entity re-identifies by resolving the alias, and the code is used for no other purpose. When the workflow instead needs an explicit code-to-PHI map, keep it on a dedicated `re-id-map/*` system- stream-adjacent subtree with access permitted only to the re-identification administrator role; the code generation method (random / hash-of-non-PHI) must not encode PHI per §514(c)(1)(ii). HDS: facilitated (effort saved: low) (mode: storage) The platform's alias primitive provides the re-identification code directly: `accesses.create {randomAlias:true}` (deployed on the HDS cores since 2026-07-28) mints a platform-unique `r-XXXXXXXX` alias that is random by construction — it does not encode PHI, satisfying §514(c)(1)(ii) out of the box — and the platform holds the alias-to-user mapping. Where a workflow instead needs an explicit code-to-PHI map, HDS supports keeping it as a tightly scoped resource reachable only by the re-identification administrator role; the code-generation method must then not encode PHI, which is the covered entity's editorial requirement. Detail: 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. Evidence: internal:hipaa/policies/de-identification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [analytics, secondary-use]; basis: entity Generate codes that do not encode PHI and restrict their use to re-identification. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.528(b) — Accounting of disclosures — implementation specifications Requirement: Each accounting entry must include the disclosure date, the recipient, a brief description of the PHI disclosed, and a brief statement of purpose or a copy of the written request. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-528-b PRYV PLATFORM: implemented Each §528(b)(2) field has a Pryv source (date / name / PHI description / purpose), see the §164.528 parent row for the mapping. The pre-computed accounting report pattern (storing results on a dedicated stream) keeps the §528 response window tractable. HDS: facilitated (effort saved: high) (mode: evidence) Each §528(b)(2) field has an audit-log source — date, recipient, PHI description and purpose — as mapped in the parent accounting row. HDS operates the audit log that supplies these fields across every region. The audit log is included verbatim in every app-portability backup (`audit_logs.json`), so individuals receive the raw §528 source data alongside their PHI in a single self-service download. Detail: 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. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, internal:hipaa/procedures/accounting-of-disclosures Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: integration Compile each accounting entry's required fields from the audit log and your records. IMPLEMENTER [individual] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You receive an accounting containing the §528(b) fields. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: integration Provide the covered entity with the disclosure details you hold. Templates to sign: baa ## hipaa-privacy 164.504(e) — Organizational requirements — business associate contracts Requirement: A covered entity may permit a business associate to create, receive, maintain or transmit PHI on its behalf only with satisfactory assurances via a written contract meeting the BAA content requirements of §164.504(e)(2). Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-504-e PRYV PLATFORM: facilitated (mode: storage) The §164.504(e) BAA content is contractual. Pryv-side support for executing the contract terms: BA access tagged with `clientData.baa_id` + `clientData.role = "business_associate"`, scope narrowed to subjects + streams covered by the BAA, audit-log accountability for every action under the BA access. HDS: facilitated (effort saved: medium) (mode: storage) HDS offers a BAA template and the technical means to execute its terms: a business-associate access tagged with the contract reference and role, scoped to the covered subjects and streams, with full audit-log accountability. The contract content itself is contractual. Detail: 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. Evidence: internal:hipaa/registers/baa-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [third-parties]; basis: entity Execute a BAA meeting §164.504(e)(2) before any business associate handles PHI. Templates to sign: baa IMPLEMENTER [business-associate] coverage: documented applies_when: [third-parties]; basis: entity Sign the BAA and execute back-to-back subcontractor agreements with downstream processors. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.504(g) — Organizational requirements — group health plans Requirement: A group health plan may disclose PHI to a plan sponsor only after receiving certification that the plan documents have been amended to incorporate the §164.504(f) restrictions. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-504-g PRYV PLATFORM: out-of-scope Group-health-plan / plan-sponsor arrangements are organizational / contractual. No software role. HDS: out-of-scope Group health plan and plan-sponsor arrangements are organizational and contractual, with no software role. HDS provides no technical control specific to this requirement. Detail: The plan-document amendment and certification are entirely the covered entity's contractual obligations. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Obtain the plan-sponsor certification before disclosing PHI to the sponsor. IMPLEMENTER [business-associate] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-privacy 164.502(j) — Disclosures by whistleblowers and workforce-member crime victims Requirement: A workforce member's or business associate's disclosure of PHI to a regulatory, oversight or law-enforcement authority is not a violation where made in good-faith belief of unlawful conduct and meeting the §502(j) conditions. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-502-j PRYV PLATFORM: out-of-scope Whistleblower protections are legal framing. No software role; the disclosing person's audit-trail evidence under their access may be cited in subsequent proceedings. HDS: documented (effort saved: low) The protection itself is a matter of law and has no software role, but HDS does carry a control for it: its workforce sanctions policy states that a good-faith protected disclosure to a regulatory, oversight or law-enforcement authority is not sanctionable conduct, and covers disclosure outside HDS as well as internal reporting. Detail: 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. Evidence: internal:hipaa/policies/workforce-sanctions Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Recognize the §502(j) protection in your policies and non-retaliation handling. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Understand the §502(j) good-faith disclosure protection. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA # HIPAA Security Rule (hipaa-security) regulation · US · 45 CFR Part 164 Subpart C (as amended through the HITECH 2013 Omnibus Final Rule) · regions: us Official text: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C HDS's own position on HIPAA-Security: - vault: HDS is not-applicable. 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. External assurance: self-assessed. No HIPAA audit, no independent Security Rule assessment and no third-party report covers HDS. The attestations on file belong to the hosting providers and cover their facilities, not HDS's practices. 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 Evidence: 40 of 43 requirements answered from approved HDS documentation (43 cite internal evidence), as of 2026-09-10. 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. NOTE: 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. Known gaps in HDS's own position: - [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. (refs: 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. (refs: 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. (refs: 164.310(d)(1)) ## hipaa-security 164.308(a)(1)(i) — Security management process — standard Requirement: Implement policies and procedures to prevent, detect, contain, and correct security violations. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-1-i PRYV PLATFORM: facilitated (mode: evidence) The Security Management Process is a programme you run as the covered entity / business associate, risk analysis, risk-management decisions, sanctions, activity review. Pryv supplies the technical raw material (audit log, system-level observability) that several of those activities draw on, particularly the §164.308(a)(1)(ii)(D) Information System Activity Review specification. The umbrella programme itself remains yours to define and run. Detail: The four implementation specifications under (a)(1)(ii), risk analysis (R), risk management (R), sanction policy (R), and information system activity review (R), each have their own row where the Pryv contribution is more direct. This row covers the umbrella standard itself: a written, maintained programme. HDS: documented (effort saved: medium) As an operator HDS runs its own security-management programme over the open-pryv.io platform, covering all four required specifications: risk analysis, risk management, sanction policy and information-system activity review. The umbrella programme is documented internally and made available on request; a partner running their own ePHI workload still maintains their own. Detail: 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. Evidence: internal:hipaa/policies/security-management-process, internal:shared/registers/technology-stack, internal:shared/registers/data-residency-regions Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Define, document and maintain your own security-management programme; you may reference HDS's technical safeguards as inputs. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Run your own security-management programme covering the ePHI you process, citing HDS substrate where it carries part of the control. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(1)(ii)(A) — Risk analysis — required implementation specification Requirement: Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-1-ii-a HDS: implemented (effort saved: low) HDS has conducted its own risk analysis over the ePHI it will hold as operator: an asset inventory covering every class in scope, a register of twenty rated risks, and a documented method. It was reviewed and approved through the internal sign-off process. The ratings are deliberately made against a populated platform even though no real patient data is held yet, so that nothing reads Low on the day real records arrive. Each partner conducts its own analysis over its own workload; a risk analysis is not a thing one entity can perform on another's behalf. Detail: 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. Evidence: internal:hipaa/risk/risk-analysis Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Conduct and document your own risk analysis over the ePHI you hold; you may use this matrix and the HDS technology-stack register as inputs to asset identification, not as a substitute for the assessment. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Conduct and document your own risk analysis over the ePHI you process. It is yours alone: the HDS analysis covers HDS's operator surface, not your workload. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(1)(ii)(B) — Risk management — required implementation specification Requirement: Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a). Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-1-ii-b HDS: implemented (effort saved: low) HDS maintains a risk-management plan whose treatment register is keyed to the identified risks, recording for each an owner, a treatment decision and a residual rating. It was reviewed and approved through the internal sign-off process. Treatment decisions are HDS's own; a partner runs the same cycle over its own analysis. Detail: 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. Evidence: internal:hipaa/plans/risk-management Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Select, implement and record treatments for the risks your own analysis identifies; the controls in this matrix are candidate measures, not a treatment decision made for you. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Select, implement and record treatments for the risks your own analysis identifies, with residual risk accepted by someone who has the authority to accept it. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(1)(ii)(D) — Information system activity review — Required Requirement: Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-1-ii-d PRYV PLATFORM: implemented Every API call is captured by Pryv's per-user audit log; the `audit.get` method exposes it for periodic review. Observability (opt-in telemetry emitter) gives system-level activity reports for the infrastructure side. The "regular review" cadence is your written procedure. Detail: Audit records carry timestamp, user, access reference (accessId + accessSerial), API method, key request fields, success / error. This is the raw material for both routine review (who accessed what, when) and incident-driven investigation. The audit-event-stream optional channel surfaces audit records into the subject's own streams, useful when the subject participates in review. HDS: implemented (effort saved: high) On top of the platform's per-user audit log, HDS operates the review substrate: system-level activity is collected and monitored across both US and Switzerland data-residency options, with alerting on crash, error-rate and silence conditions. The written procedure sets a quarterly cadence and a sign-off record. Two parts of it are not yet operating: sampling the per-user audit log for anomalies is the step that remains outstanding, tracked as an open risk-analysis item, and the platform telemetry channel is mid-transition (see the planned chip), with the in-process vendor agent removed on 2026-07-28 in favour of an allow-list, aggregate-only emitter. Until the self-hosted collector and rebuilt alert chain are verified, platform-core detection leans on synthetic and liveness checks. Detail: 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. Evidence: internal:hipaa/procedures/information-system-activity-review Evidence backing: every internal document cited above has completed approval. PLANNED (feature, impact medium): Platform telemetry is moving from a vendor in-process agent (removed 2026-07-28) to a self-hosted OTLP collector fed by the platform's allow-list aggregate emitter; collector deployment, alert-chain rebuild and end-to-end delivery verification are the tracked remainder. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Define and document your review cadence and who performs it, and retain the review records per your retention policy. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Establish your own periodic review of activity records for the ePHI you process, drawing on the audit and monitoring substrate HDS exposes. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(2) — Assigned security responsibility — standard Requirement: Identify the security official who is responsible for developing and implementing the policies and procedures required by this subpart. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-2 PRYV PLATFORM: out-of-scope Security-official designation is HR / organizational. No software role. When the assigned official needs operational data, the audit log + observability + this matrix are the substrate they draw on. HDS: implemented (effort saved: low) HDS has designated its Security Official: appointed by the CEO on behalf of the HDS Foundation, effective 2026-07-15, recorded in the designated- roles register and the governing policy, both approved and disclosed on request. Each partner must designate their own official for their own programme. Detail: 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. Evidence: internal:hipaa/policies/assigned-security-responsibility, internal:hipaa/registers/designated-roles Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Designate and document your own security official. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Designate and document your own security official. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(3)(ii)(C) — Termination procedures — Addressable Requirement: Implement procedures for terminating access to ePHI when employment ends or a workforce member's role changes. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-3-ii-c PRYV PLATFORM: implemented Workforce access to ePHI is mediated by Pryv accesses. Termination is a single API call (`accesses.delete`) which immediately revokes the token. The audit log proves the termination instant. For role-change scenarios, `accesses.update` narrows permissions without full revocation, preserving the version history of the change. Detail: The "Addressable" status means you must implement it, document why not, or implement an equivalent. The Pryv primitives give you the "implement it" path directly: - Full termination: `accesses.delete` revokes the token immediately and snapshots the prior state into the access history. - Role change / narrowing: `accesses.update` with reduced `permissions` keeps the same access identity but enforces the new scope from the version bump onward. - Audit chain: every subsequent API call would fail authentication (after delete) or fall outside the new scope (after update), producing a verifiable termination boundary. For workforce-scale deployments (e.g., hospital with 100+ staff), Pryv composes with two patterns covered in `context/workforce-access-patterns.md`: - Group access + `callerId` (auth header `Authorization: `), termination = removing the individual from the external IdP / IGA group, no Pryv- side action; audit trail preserves the individual identity via the recorded caller id. - Seed access + sub-access derivation, termination = `accesses.delete` on the individual's sub-access while the seed + sibling sub-accesses remain untouched. Roles + groups are deliberately outside Pryv; the external IdP is the source of truth. HDS: implemented (effort saved: high) Workforce termination at HDS revokes operator and infrastructure access: platform admin and service credentials, hosting hosts, monitoring, the alert mailbox, code repositories carrying deploy rights, and any break-glass grant. It is a dated ticket rather than a single switch, because shared secrets must also be rotated, and it does not touch a user's own data-sharing tokens, which belong to the user and are unaffected by offboarding. Detail: 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. Evidence: internal:hipaa/procedures/access-termination Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Document your termination workflow and tie it to revocation of the access tokens your workforce holds. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Document your termination workflow for staff who handle the ePHI you process on HDS. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(4)(ii)(B) — Access authorization — Addressable Requirement: Implement policies and procedures for granting access to ePHI through a workstation, transaction, program, process, or other mechanism. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-4-ii-b PRYV PLATFORM: implemented Granting access to ePHI in Pryv means minting an access with explicit per-stream permissions. The technical authorization decision is enforced at every API call. Documentation of the authorization rationale lives in `access.clientData` next to the grant itself, so the "why" travels with the "what". Detail: Access grants are creation events on the `accesses` collection, with `permissions[]` listing the streamId + level tuples the grantee may exercise. `clientData` carries free-form metadata such as the workforce-role label, the granting administrator, the business reason. Together these form a per-grant record satisfying both the technical control and the documentation half of the standard. HDS: implemented (effort saved: high) Granting access to ePHI on HDS means minting an access token with explicit per-stream permissions, enforced at every API call. The authorization rationale can travel alongside the grant itself, so the "why" stays with the "what". Two authorisation paths are kept apart: access to a user's own ePHI is decided by that user, while operator and infrastructure access is decided by HDS under least privilege. Detail: 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. Evidence: internal:hipaa/policies/access-authorization Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Document who may authorise access and on what basis, and capture the rationale alongside each grant. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Document your authorization policy for access to the ePHI you process. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(4)(ii)(C) — Access establishment and modification — Addressable Requirement: Implement policies and procedures to establish, document, review, and modify a user's right of access, based on the entity's access authorization policies. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-4-ii-c PRYV PLATFORM: implemented The access lifecycle (create / read / update / delete) is first- class in Pryv. `accesses.update` writes a tamper-evident snapshot of the prior version into history on every modification, giving you the documented review trail this standard expects. Detail: Modification semantics: - `accesses.create`: establishes a new grant (see (a)(4)(ii)(B)). - `accesses.get ?includeHistory=true`: review the version chain. - `accesses.update`: modify permissions / clientData; bumps `serial`, snapshots the old head into history. - `accesses.delete`: termination (see (a)(3)(ii)(C)). Every step appears in the audit log, with the timestamp and acting administrator's identity preserved. HDS: implemented (effort saved: high) The access lifecycle (create, read, review, update, revoke) is first-class on the platform HDS operates. Every modification snapshots the prior version into history and is recorded in the audit log, giving the documented review trail this specification expects. Detail: 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. Evidence: internal:hipaa/procedures/access-review, internal:procedures/access-review/executions/2026-07-30-1 IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Document your establishment-and-modification workflow and your periodic access-review cadence. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Document how you establish, review and modify access to the ePHI you process on HDS. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(5)(ii)(A) — Security reminders — Addressable Requirement: Implement periodic security updates and reminders for the workforce. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-5-ii-a PRYV PLATFORM: out-of-scope Reminder cadence + content are organizational. Pryv has no role at the awareness-content layer. HDS: facilitated (effort saved: low) (mode: awareness) Security-reminder cadence and content are an organisational awareness control with no software role. HDS runs reminders for its own workforce as part of a workforce-training programme it operates continuously, tracking certifications in a completion register and flagging overdue members. Two pieces are still being assembled rather than absent: the HDS-specific curriculum material, and the outstanding policy acknowledgements. The written programme is available on request. Detail: 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. Evidence: internal:hipaa/policies/security-awareness-reminders Evidence backing: every internal document cited above has completed approval. PLANNED (procedure, impact medium): The workforce-training procedure is approved and the completion register holds dated third-party certifications for every workforce member, with expiry reminders wired to the internal tasks board. What remains is the HDS-specific curriculum, the recorded acknowledgements, and letting the monthly cadence run a first full cycle: no per-occurrence execution record has been filed yet. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Run and document your own periodic security reminders for your workforce. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Run and document your own security reminders for staff handling ePHI. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(5)(ii)(B) — Protection from malicious software — Addressable Requirement: Implement procedures for guarding against, detecting, and reporting malicious software. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-5-ii-b PRYV PLATFORM: out-of-scope Anti-malware is a host / endpoint / network-layer control, Pryv-the-software doesn't include AV. Same out-of-scope reasoning as ISO 27001 A.8.7. The operator's hosting environment carries this control. HDS: facilitated (effort saved: low) (mode: infrastructure) Anti-malware here is a host, endpoint and network-layer concern rather than a platform feature. HDS runs no dedicated anti-malware agent on its Linux hosts, and states that as a deliberate decision rather than an omission: protection rests on OS and platform patching, dependency scanning, a minimised attack surface and monitoring. The partner's own endpoints remain the partner's responsibility. Detail: 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. Evidence: internal:hipaa/policies/malware-protection Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Operate and document anti-malware controls on your own endpoints and infrastructure. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Operate and document anti-malware controls on infrastructure you run outside HDS. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(5)(ii)(C) — Log-in monitoring — Addressable Requirement: Implement procedures for monitoring log-in attempts and reporting discrepancies. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-5-ii-c PRYV PLATFORM: facilitated (mode: evidence) Login + authentication- failure events are captured in the audit log (per `auth.*` API method calls). Observability data aggregates rate + anomaly signals. The discrepancy-reporting cadence + threshold tuning are operator-side procedure. Detail: **Pryv surfaces the events; operator chooses the lockout policy.** Pryv does not in-process rate-limit login attempts or lock accounts after N failures by itself (deliberate; multi-core deployments make in-process counters mis-fire + lockout sensitivity is workload-specific). Operator pattern: `fail2ban` watching the audit log + banning IPs that exceed N auth failures in T minutes; reverse-proxy `limit_req_zone` for per-IP rate caps on `/auth/login`. Full operator-side rate-limiting framing + reference-config backlog: `context/rate-limiting-and-dos-protection.md` + internal backlog slug `RATE-LIMITING-RECIPES`. PLANNED (enhancement, impact low): Reference reverse-proxy rate-limiting configurations add an enforcement companion to log-in monitoring on the authentication endpoints HDS: facilitated (effort saved: medium) (mode: evidence) Authentication and login-failure events are captured in the per-user audit log, and reverse-proxy and host auth logs are retained on HDS infrastructure. Review is quarterly and manual: automated login-anomaly detection and alert thresholds for this specification are not formalised, which HDS names as the current gap rather than implying continuous detection. Detail: 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. Evidence: internal:hipaa/procedures/login-monitoring Evidence backing: every internal document cited above has completed approval. PLANNED (platform, impact low): Upstream reference reverse-proxy rate-limiting configurations would add an enforcement companion to login monitoring on the authentication endpoints, once shipped and adopted in the HDS deployment. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Define and document your discrepancy thresholds and the response when a threshold is crossed. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Define and document login-monitoring thresholds for the ePHI workload you operate. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(5)(ii)(D) — Password management — Addressable Requirement: Implement procedures for creating, changing, and safeguarding passwords. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-5-ii-d PRYV PLATFORM: configurable Pryv stores credentials on a privileged `system-stream`, separate from ordinary content. Password rules (complexity, rotation) are operator-configured. Adding `services.mfa.mode` raises the authentication strength beyond a password alone, see §164.312(d). Detail: Password is one possible factor; MFA via the `mfa.*` API methods (SMS-based by default) is the second factor when enabled. Recovery flows live alongside (`mfa.recover`) so an account is not lost when a device is. The implementer chooses whether MFA is required universally or per-role. PLANNED (enhancement, impact low): Reference TOTP / WebAuthn plugins reduce dependence on SMS-OTP for the second factor HDS: implemented (effort saved: medium) The platform stores credentials on a privileged, separately controlled namespace, and HDS configures password rules and offers a second authentication factor on top. HDS operates and documents the resulting password-management posture. Detail: 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. Evidence: internal:hipaa/procedures/password-management Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Document your password policy and whether you require the second factor for your workforce. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Document password-management procedures for staff handling ePHI. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(6)(i) — Security incident procedures — standard Requirement: Implement policies and procedures to address security incidents. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-6-i PRYV PLATFORM: facilitated (mode: evidence) Incident-response procedure is the operator's organizational programme. Pryv contributes the detection + scoping data layer: audit log shows who accessed what; observability gives system-level anomaly signals; access primitives provide the containment mechanism (revoke or scope-down the implicated access). For substrate-vulnerability intake specifically (operator learning that the Pryv version they run has a confirmed vulnerability), the upstream's vulnerability disclosure program is the externally-facing channel: `SECURITY.md` publishes a coordinated disclosure policy (private GitHub Security Advisories flow + `security-dev@` mailbox + scope + SLA + safe harbor), and private vulnerability reporting is enabled on the published repositories. HDS: documented (effort saved: medium) HDS runs an incident-response programme as operator: the audit log and operational monitoring provide detection and scoping data, and access tokens provide the containment mechanism (revoke or narrow the implicated access). The written incident procedure is held internally and shared on request. Detail: 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. Evidence: internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Run and document your own incident-response procedures. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Run and document your own incident procedures and report incidents to the covered entity per your BAA. Templates to sign: baa IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(7)(ii)(A) — Data backup plan — Required Requirement: Establish and implement procedures to create and maintain retrievable exact copies of ePHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-7-ii-a PRYV PLATFORM: implemented `bin/backup.js` produces per-user backup files (events, streams, accesses, attachments). `--restore` rebuilds a user from a backup file. The backup procedure ("when, where, how often") is yours to schedule; the underlying primitive is shipped. Detail: Per-user backup files are advantageous for HIPAA's "exact copies" language because the backup unit matches the natural protected- health-information unit (the subject). They also play well with the §164.310(d) media controls (you can encrypt + transport a single subject's backup file). **Encryption-at-rest of the backup archive is operator-side by design**; Pryv produces an unencrypted dump file; the operator pipes it through their encryption-at-rest layer (LUKS on the backup volume, GPG / age before offsite ship, S3 SSE-KMS / Azure SSE / customer-managed keys on bucket- level encryption) at the storage boundary. Same pattern as the broader bulk-event-data at-rest encryption posture (see `proposals/e2e-encryption.md`, operator-side infrastructure layer is the deliberate choice; CMEK / BYOK / encrypted dumps live there). Implementer documents the chosen encryption scheme in their backup-plan SOP for §164.308(a)(7)(ii)(A) compliance. HDS: facilitated (effort saved: high) (mode: storage) The platform produces per-user backup files (events, streams, accesses, attachments) with a matching restore path, so the backup unit matches the natural ePHI unit. HDS runs the cycle automatically on a daily timer on each regional core, first verified live on all cores on 2026-07-30, with a host-side watchdog that alerts when an expected archive is absent. What is not demonstrated is restore at production scale per region, which is why this reads as facilitated rather than fully implemented. Detail: 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. Evidence: internal:hipaa/procedures/data-backup-plan, internal:procedures/backup-run/executions/2026-07-30-1 PLANNED (procedure, impact medium): Automated, restore-verified backups are the tracked remediation. Provisioned and verified 2026-07-29: in-region off-host object storage in each region (Swiss and US) with object versioning; HDS-held hybrid encryption of every archive (a per-run AES-256-GCM key wrapped to a per-region RSA-4096 public key, the private key held off-host); least-privilege per-host access; and defined targets (RPO 24h, RTO 72h, retention a flat 30 days, the grandfather-father-son promotion having been retired 2026-09-02). The scheduled cycle is running on all regional cores as of 2026-07-30, and retrievability was demonstrated by fetching an archive off-host and decrypting it with the off-host private key. Outstanding before this is fully implemented: the per-region production restore drill at non-trivial scale, and confirmation of the storage lifecycle backstop. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: integration Document your backup schedule, storage location and retention, and confirm restorability. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: integration Document the backup plan for the ePHI you process on HDS. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(7)(ii)(B) — Disaster recovery plan — Required Requirement: Establish, and implement as needed, procedures to restore any loss of data. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-7-ii-b PRYV PLATFORM: configurable Two layers Pryv gives you: (1) cold restore from `bin/backup.js --restore`, the canonical recovery path; (2) hot redundancy via a multi-core cluster (rqlite replication + cluster-CA mTLS between cores), so a single-region failure doesn't lose live data. You compose them per your RTO / RPO. Detail: Cluster topology is documented in the dev-site customer-resources guides. The bootstrap CLI (`bin/bootstrap.js new-core`) issues an encrypted bundle with the cluster CA + rqlite TLS material; the joining core boots via `bin/master.js --bootstrap`. Lets-Encrypt certificates replicate across the cluster via rqlite keys, so a surviving core can serve TLS without re-issuing. HDS: documented (effort saved: medium) HDS combines cold restore from per-user backups with hot redundancy from a replicated multi-core platform topology, composed to a recovery objective HDS documents internally. The written disaster-recovery plan is available on request. Detail: 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. Evidence: internal:hipaa/procedures/disaster-recovery-plan Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: integration Document your recovery objectives and the steps to restore data after a loss event. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: integration Document the disaster-recovery procedures for your ePHI workload. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(7)(ii)(C) — Emergency mode operation plan — Required Requirement: Establish, and implement as needed, procedures to enable continuation of critical business processes for protection of ePHI while operating in emergency mode. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-7-ii-c PRYV PLATFORM: facilitated (mode: infrastructure) Pryv's HA primitives (multi-core cluster + Raft replication + cluster-CA mTLS) support continued operation when a single facility fails. The "critical business processes" definition + emergency-mode runbook are the operator's. See also Art.5+ of the Disaster Recovery row. HDS: documented (effort saved: medium) The platform's high-availability primitives (a replicated multi-core cluster with mutually authenticated inter-core traffic) support continued operation when a single facility fails. HDS documents which processes are critical and holds an emergency-mode runbook whose governing rule is to fail closed: if a security control cannot be kept up while degraded, the affected function is restricted or suspended rather than serving ePHI without it. The runbook is written but unexercised, since no degraded-operation event has occurred and no exercise has yet been run. Detail: 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. Evidence: internal:hipaa/procedures/emergency-mode-operation Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: integration Define your critical processes and document the emergency-mode runbook. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: integration Document emergency-mode procedures for the ePHI you process. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(7)(ii)(D) — Testing and revision procedures — Addressable Requirement: Implement procedures for periodic testing and revision of contingency plans. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-7-ii-d PRYV PLATFORM: out-of-scope Contingency-plan testing is an operational drill. Pryv has no software role at the drill-execution layer. The drill's restoration-from-backup phase exercises Pryv primitives but the testing programme itself is the operator's. HDS: documented (effort saved: low) Contingency-plan testing is an operational drill whose restore phase exercises the platform's backup-restore path. HDS is formalising a regular test-and-revise cadence; the procedure is documented internally and regular verified execution remains a known gap. Detail: 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. Evidence: internal:hipaa/procedures/contingency-plan-testing, internal:procedures/contingency-test/executions/2026-07-29-1 PLANNED (procedure, impact medium): The contingency-test procedure is approved and the first restore rehearsal was performed on 2026-07-29 and filed as an execution record. It covered a single account, not a full per-region restore, so the tracked remainder is recovery at production scale in each region. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: integration Schedule, run and document periodic tests of your contingency plans and revise them based on results. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: integration Test and revise your contingency plans periodically and keep the records. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.308(a)(8) — Evaluation — standard Requirement: Perform periodic technical and nontechnical evaluation, in response to environmental or operational changes, to confirm that security policies and procedures continue to meet the requirements of this subpart. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-308-a-8 PRYV PLATFORM: facilitated (mode: evidence) Evaluation is the operator's cyclical assessment. Pryv-side inputs: audit log (control- effectiveness sample), observability (operational stability data), this matrix (control inventory to evaluate against), Pryv's test matrix (~2351 PG and SQLite, matched baseline, passing on every commit, concrete §164.308(a)(8) effectiveness evidence), Pryv's supply-chain pipeline (shipped in open-pryv.io `9e2ee7ff`: CI dependency-audit gate, per-release CycloneDX SBOM, cosign-signed images; the SBOM + latest scan output are citable periodic-evaluation artefacts), Pryv's vulnerability disclosure program + GHSA advisory history (coordinated disclosure policy published in `SECURITY.md`; private vulnerability reporting enabled on the published repositories). The assessment write-up is operator-side. PLANNED (feature, impact medium): Read-only effective-configuration endpoint supplies the technical baseline snapshot the periodic evaluation is measured against HDS: documented (effort saved: low) HDS has defined a periodic evaluation of its security programme, drawing on the audit log, operational monitoring, this matrix as a control inventory, and the platform's test results as control-effectiveness evidence. The annual cadence is established and the procedure approved, but no cycle has completed yet, so this standard is defined rather than evidenced by a record. Detail: 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. Evidence: internal:hipaa/procedures/periodic-evaluation Evidence backing: every internal document cited above has completed approval. PLANNED (platform, impact low): A read-only effective-configuration endpoint queued upstream would supply the per-core technical baseline snapshot this evaluation is measured against, once shipped and deployed by HDS. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Perform and document your own periodic technical and nontechnical evaluation. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Perform and document a periodic evaluation of the safeguards over the ePHI you process. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.310 — Physical Safeguards — standard (framing) Requirement: Implement policies and procedures to limit physical access to electronic information systems and the facilities in which they are housed, while ensuring that properly authorized access is allowed. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-310 PRYV PLATFORM: facilitated (mode: awareness) Physical safeguards (facility access, workstation security, device and media controls) are properties of the hosting environment, not of the Pryv software itself. Pryv contributes two things: the data-residency primitive lets you bind a user's data to a specific hosting (so you can certify the physical environment for that data explicitly), and operator-supplied secrets are AES-256-GCM encrypted at rest so that a stolen disk doesn't leak the keys themselves. Detail: For each implementation specification under §164.310 ((a)(1) facility access controls, (b) workstation use, (c) workstation security, (d) device and media controls), the controls are physical and operational. Pryv's posture: the operator chooses + documents the hosting environment; for multi-hosting deployments, `data-residency` lets you certify the physical layer differently per region. Per- user backup files (see §164.308(a)(7)(ii)(A)) are the unit of device-and-media-controls transfer when you need to move a single subject's ePHI off-host. HDS: facilitated (effort saved: medium) (mode: infrastructure) Physical safeguards are properties of the hosting environment, not of the open-pryv.io software. HDS carries this layer by selecting certified hosting providers (EU/Switzerland and US data-residency options) and documenting the facility-control attestations it relies on, so an implementer inherits a vetted physical posture rather than sourcing it themselves. Detail: 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. Evidence: internal:hipaa/policies/physical-safeguards, internal:hipaa/registers/hosting-provider-attestations Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy]; basis: integration Rely on the HDS-selected hosting region for the server-side facility controls; you remain responsible for the physical security of your own offices, endpoints and any workforce devices that access ePHI. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy]; basis: integration Inherit the HDS hosting-region facility posture and document it in your own physical-safeguards programme; cover your own premises and devices. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.310(a)(1) — Facility access controls — standard Requirement: Implement policies and procedures to limit physical access to electronic information systems and the facilities housing them, while ensuring properly authorized access is allowed. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-310-a-1 PRYV PLATFORM: out-of-scope Facility access is physical. See the §164.310 framing row. HDS: facilitated (effort saved: medium) (mode: infrastructure) Facility access control at the server tier is delivered by the certified hosting provider for the chosen region. HDS selects providers whose data-centre access controls (badged entry, escort policies, access logging) are independently attested, and documents which attestation backs each region. Detail: 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. Evidence: internal:hipaa/registers/hosting-provider-attestations, internal:hipaa/policies/physical-safeguards Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy]; basis: integration Inherit the server-tier facility controls from the HDS hosting region; implement and document facility access controls for your own premises. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy]; basis: integration Inherit the server-tier facility controls from the HDS hosting region, and implement and document facility access controls for your own premises. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.310(b) — Workstation use — standard Requirement: Implement policies and procedures specifying the proper functions to be performed, how they are to be performed, and the physical attributes of the surroundings of any workstation or class of workstation that can access ePHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-310-b PRYV PLATFORM: out-of-scope Workstation use + physical attributes are facility / HR controls. HDS: documented (effort saved: low) Workstation use is a workforce and endpoint-management control that sits with the entity operating the workstations, not with the HDS platform. HDS documents the assumption that ePHI access happens only through authenticated, access-token-scoped sessions, which bounds what any single workstation can do. Detail: 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. Evidence: internal:hipaa/policies/physical-safeguards Evidence backing: every internal document cited above has completed approval. PLANNED (doc, impact low): A workstation and BYOD standard now states what any machine must be before it may hold credentials that reach ePHI, and is approved. Its evidence is the countersigned per-machine attestation record: two of the three machines in scope are attested and awaiting countersignature, and one is not yet assessed. Completing them is the tracked remediation. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Define and document workstation-use rules for the devices your workforce uses to access ePHI through the HDS-hosted application. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Define and document workstation-use rules for the devices your workforce uses to reach ePHI. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.310(c) — Workstation security — standard Requirement: Implement physical safeguards for all workstations that access ePHI, to restrict access to authorized users. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-310-c PRYV PLATFORM: out-of-scope Physical workstation security (screen locks, kensington locks, privacy filters) is endpoint-management scope. HDS: documented (effort saved: low) Physical workstation security (screen locks, device controls, premises) is endpoint-management scope owned by the entity operating the workstation. HDS documents the compensating platform control: a lost or unattended workstation cannot exceed the permissions of its access token, and the token can be revoked centrally. Detail: 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. Evidence: internal:hipaa/policies/physical-safeguards Evidence backing: every internal document cited above has completed approval. PLANNED (doc, impact low): A workstation and BYOD standard now states what any machine must be before it may hold credentials that reach ePHI, and is approved. Its evidence is the countersigned per-machine attestation record: two of the three machines in scope are attested and awaiting countersignature, and one is not yet assessed. Completing them is the tracked remediation. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Implement physical workstation safeguards (screen locks, restricted siting, device management) for endpoints accessing ePHI; revoke HDS access tokens on device loss. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Implement physical safeguards on your own endpoints (screen locks, restricted siting, device management), and revoke HDS access tokens on device loss. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.310(d)(1) — Device and media controls — standard Requirement: Implement policies and procedures governing the receipt and removal of hardware and electronic media containing ePHI into and out of a facility, and the movement of these items within the facility. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-310-d-1 PRYV PLATFORM: facilitated (mode: infrastructure) Pryv-side contribution at the media-controls layer: per-user backup files are the natural unit when an individual subject's ePHI moves off the production system (export, transfer, archive); operator-side at-rest encryption (LUKS / PG TDE) keeps the ePHI-on-media encrypted in motion + at rest. The physical movement procedure is the operator's. HDS: facilitated (effort saved: medium) (mode: infrastructure) Media disposal and re-use at the server tier are handled by the certified hosting provider's media-sanitisation controls, which HDS selects and documents. For per-subject ePHI movement, the platform's per-user export unit is the natural medium so a single subject's data can be transferred or archived discretely. Detail: 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. Evidence: internal:hipaa/registers/hosting-provider-attestations, internal:hipaa/procedures/media-controls, internal:hipaa/evidence/at-rest-encryption-verification Evidence backing: every internal document cited above has completed approval. PLANNED (doc, impact low): Swiss region only. The US region's media-sanitisation evidence is on file (AWS third-party attestations obtained 2026-07-28), so the collection remediation is discharged for that half. Nothing is on file for the Swiss region, whose provider is contractually obliged to supply a current ISO/IEC 27001 certificate and SOC 2 Type II summary on request; obtaining them is the remaining remediation. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: integration Inherit server-tier media sanitisation from the hosting provider; apply your own at-rest encryption to any per-subject export you move off the platform, and document the movement. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: integration Inherit server-tier media sanitisation from the hosting provider, and apply your own at-rest encryption to any export you move off the platform, documenting the movement. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(a)(1) — Access control — standard Requirement: Implement technical policies and procedures for electronic information systems holding ePHI so that access is allowed only to persons or software programs granted access rights under §164.308(a)(4). Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-a-1 PRYV PLATFORM: implemented Per-stream permissions are enforced at every API call; an access can read or write only the streams its `permissions[]` lists, at the level granted. There is no "bypass on trust" path, the enforcement is the API surface, not a downstream policy layer. System streams (account, password, MFA) sit on a separately controlled namespace. Detail: The standard's four implementation specifications below each map to a distinct Pryv concern. The standard itself is the umbrella: the technical control system that prevents access by anyone / anything not granted it. **Cross-user isolation caveat:** the "no bypass on trust path" property holds at the API surface. The strength of the underlying isolation depends on the chosen storage engine, SQLite gives physical per-user-file isolation; PG gives logical app-code-enforced isolation against shared tables. See `context/per-engine-isolation.md` for the per-engine breakdown + operator mitigation patterns (PG row-level security, per-schema, per-account-DB, per-tenant deployments). **Scope-gated OAuth2 grants.** The delegated-app access path (OAuth2 authorization-code + PKCE, `open-pryv.io/components/oauth2/`, open-pryv.io 2.0.0-rc.8) inherits the same permission enforcement: an authorization-code grant references exactly one consent offer and mints an app access whose `permissions[]` are the user's granted subset of that offer; it can touch nothing outside them. Presented redirect URIs are validated by exact string match (loopback-port carve-out only; fragment-bearing URIs rejected, `open-pryv.io/components/oauth2/src/clientRegistry.ts`), so an issued authorization code cannot be diverted to an unregistered callback. HDS: implemented (effort saved: high) HDS deploys open-pryv.io with per-user data isolation and per-stream access tokens enforced at every API call: a token can read or write only the streams its permissions list, at the level granted. On that platform path there is no trust-based bypass, and no HDS role can grant itself an access into a user account. Access control is therefore a technical property of the API surface HDS operates rather than a downstream policy layer. Infrastructure access is a separate path that the API does not mediate, and it is bounded by authorisation rather than by this mechanism (see §164.308(a)(4)(ii)(B)). Detail: 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. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects]; basis: integration Configure your application's use of HDS access tokens to grant least- privilege per-stream access, and document your access-authorization rules. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects]; basis: integration Model your grants as least-privilege per-stream access tokens, and document your access-authorization scheme. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(a)(2)(i) — Unique user identification — Required Requirement: Assign a unique name and/or number for identifying and tracking user identity. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-a-2-i PRYV PLATFORM: implemented Every Pryv account has a unique username + cuid; every access derived from it carries a unique access id (cuid) and version serial. Audit records cite the (accessId, accessSerial) tuple, so each tracked action ties back to a unique identity. HDS: implemented (effort saved: high) Every account in the HDS-operated platform has a unique identifier, and every access token derived from it carries a unique id and version. The per-user audit log cites that access identity on every recorded action, so each tracked operation ties back to a unique identity. Detail: 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. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects]; basis: integration Map each workforce member or program to a distinct identity/access token and document the mapping; avoid shared credentials. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects]; basis: integration Map each workforce member or program to a distinct identity and access token, and document the mapping. Avoid shared credentials. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(a)(2)(ii) — Emergency access procedure — Required Requirement: Establish (and implement as needed) procedures for obtaining necessary ePHI during an emergency. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-a-2-ii PRYV PLATFORM: configurable The operator-held admin access key (`auth.adminAccessKey`) is the break-glass mechanism: it grants administrative reads not requiring an ordinary user's consent. You document the circumstances under which it may be exercised and the audit-trail review that must follow. Detail: The admin access key is operator-side and rotates only at operator-supplied cadence, treat it as a privileged credential under custody controls equivalent to a root password. Every API call made under the admin key is audited like any other, so post-emergency review is concrete. HDS: configurable (effort saved: medium) The platform provides an operator-held administrative access mechanism that serves as a break-glass path to ePHI during an emergency, and every action taken under it is captured by the per-user audit log. HDS runs its own approved procedure over that mechanism: the Security Official authorises each grant with a stated scope and justification, time-boxes it to 24 hours by default, and reviews the audit and host logs against the grant within two business days. An implementer authors the equivalent procedure for its own workload. Detail: 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. Evidence: internal:hipaa/procedures/emergency-access Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: configurable applies_when: [connects, stores-phi-copy]; basis: integration Define and document your emergency-access procedure — who may invoke break-glass access, under what conditions, and the mandatory audit review afterward. IMPLEMENTER [business-associate] coverage: configurable applies_when: [connects, stores-phi-copy]; basis: integration Define and document your emergency-access procedure over the platform mechanism: who may invoke break-glass access, under what conditions, and the mandatory audit review afterward. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(a)(2)(iii) — Automatic logoff — Addressable Requirement: Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-a-2-iii PRYV PLATFORM: configurable Two configurables: personal-token session lifetime (`auth.sessionMaxAge`) and per-access expiry (`access.expires`). The latter is per-grant (the access is automatically inert after the timestamp passes), useful for clinical-workflow accesses whose validity is bounded by the case. Detail: Note that HIPAA's "automatic logoff" is workstation-centric in origin (workforce members stepping away from a terminal). In a Pryv-mediated workflow, the analogous control is the validity window of the access token. Combining `auth.sessionMaxAge` (for interactive workforce sessions) with per-grant `access.expires` (for app-driven background processes) covers both shapes. HDS: configurable (effort saved: high) The platform enforces automatic session and token expiry: interactive session lifetime and per-grant access-token expiry can both be bounded, so a session or token becomes inert automatically once its window passes. HDS operates the mechanism; the implementer sets the timeouts appropriate to its workflow. Detail: 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. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: configurable applies_when: [connects]; basis: integration Set session and access-token expiry windows appropriate to your workflow and document the inactivity-timeout decision. IMPLEMENTER [business-associate] coverage: configurable applies_when: [connects]; basis: integration Set session and access-token expiry windows appropriate to your workflow, and document the inactivity-timeout decision. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(a)(2)(iv) — Encryption and decryption — Addressable Requirement: Implement a mechanism to encrypt and decrypt ePHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-a-2-iv PRYV PLATFORM: configurable The "mechanism to encrypt and decrypt ePHI" is delivered as switch-on Pryv software. User PHI/PII at rest (events, attachments, series, audit, platform DB) is encrypted by the `container-encrypted-volume` companion (`encryption-at-rest-user-data`), layered onto the image, it mounts an encrypted volume on boot so the application stores ciphertext at rest. The operator enables it (`CEV_ENABLED`) and chooses a key source. Pryv additionally encrypts operator-supplied secrets at rest (AES-256-GCM, HKDF-derived) and provides TLS-in-transit via the built-in ACME integration. Detail: `container-encrypted-volume` (v0.1.0, shipped 2026-06-23) provisions and mounts a LUKS-encrypted volume inside the container and points the data roots at it, verified end-to-end (an event written through the API is unreadable in the stopped container file). Pluggable backend (LUKS reference + gocryptfs) and key provider (`env` / `file` / `exec` / `clevis` for TPM2·Tang·PKCS#11 / `aws-kms` envelope). With an identity-bound provider no copyable key is held; key custody is intrinsic to the control, not a Pryv gap. Rotation uses LUKS key-slots (no bulk re-encrypt). Volume encryption also grounds the breach-notification safe harbor (NIST SP 800-111). Coverage is `configurable`, Pryv's software performs the encryption once enabled, a step above the operator-implements-it tier. Caveats: an external PostgreSQL data dir and remote object storage (S3) are outside the mount (encrypt operator-side / via bucket SSE); LUKS needs `--privileged`. See `proposals/container-encrypted-volume.md`. The platform-secret at-rest encryption (Let's Encrypt account keys, observability tokens, cluster bootstrap bundles) remains on by default (`encryption-at-rest-secrets`). Longer-term direction: end-to-end encryption where the server never holds plaintext, research direction tracked under internal backlog slug `E2E-ENCRYPTION` (proxy re-encryption); per-row impact in `proposals/e2e-encryption.md`. PLANNED (feature, impact medium): End-to-end (server-blind) encryption via proxy re-encryption brings CMEK / BYOK to the Pryv layer HDS: implemented (effort saved: medium) ePHI is encrypted at rest in both hosting regions, and TLS protects it in transit by default. Each core's storage volume is encrypted at the hosting layer: Exoscale encrypts compute root volumes by default (AES-256-XTS, ch1/Switzerland); AWS EBS volume encryption is enabled on the US core (AES-256, us1). Verified 2026-06-26. Keys are provider-managed (AWS / Exoscale, both BAA subprocessors) — this satisfies the addressable mechanism and grounds the §164.402(2) breach safe-harbor for lost/stolen media, but is not operator-held-key or end-to-end encryption (see hipaa/risk/at-rest-encryption for the residual). Detail: 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. Evidence: internal:hipaa/policies/encryption, internal:hipaa/risk/at-rest-encryption, internal:hipaa/evidence/at-rest-encryption-verification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: configurable applies_when: [stores-phi-copy]; basis: integration HDS encrypts ePHI at rest with provider-managed keys. In your own risk analysis, decide whether that key model is sufficient or whether you need operator-held-key or application-side encryption of sensitive fields on top, and document the addressable decision. IMPLEMENTER [business-associate] coverage: configurable applies_when: [stores-phi-copy]; basis: integration HDS encrypts ePHI at rest with provider-managed keys. Decide in your own risk analysis whether that key model is sufficient or whether you need application-side encryption on top, and document the addressable decision. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(b) — Audit controls — standard Requirement: Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing or using ePHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-b PRYV PLATFORM: implemented Pryv's per-user audit log records every API method invocation, timestamp, user, access reference, method, success / error. The `audit.get` API method surfaces it for examination. The optional audit-event-stream channel additionally emits audit records into the subject's own streams, so the subject (and any access they authorise) can examine the history. Detail: Audit storage uses SQLite directly (not the engine-agnostic mall layer), to keep the audit path independent of the data path. This decouples integrity of the log from issues in the primary engine. Audit row content is data-minimal **by construction**: action + source (transport + ip) + URL query + access ref + optional integrity hash of the affected event. The request body is never stored. Consequence: an auditor reviewing the §164.312(b) log sees *who did what when* without the log itself becoming a second copy of PHI, favourable under §164.502(b) minimum- necessary review. See `docs/pryv-primitives.md` audit entry. One scoping nuance: `events.get` content-query conditions sent over HTTP GET are part of the URL query, so the **search values** your apps submit (which may reference PHI, e.g. a diagnosis code) are recorded as-is, deliberately, since the search criteria are the auditable action. Tier the audit log's protection accordingly. See `context/content-query-audit-semantics.md`. Since open-pryv.io `07b6d3b6`, the OAuth2 authorization server records its own activity in the same audit pipeline (`oauth.*` events): consent lifecycle (shown / granted / refused), authorization-code exchange including replay attempts, and token lifecycle (issued per grant type / refreshed / revoked / reuse-detected). User-resolved events land in the subject's per-user trail (`[OE07]` proves rows in `:_audit:`); the pre-identification ones (consent shown / refused, code replay) go to syslog. A detected refresh-token replay additionally revokes the whole token chain and records both the detection and the resulting revocation (open-pryv.io `829f7238`), so the §164.312(b) trail covers delegated-app authorization activity, not just data access. PLANNED (feature, impact low): Chained / signed audit log strengthens tamper-resistance evidence HDS: implemented (effort saved: high) The HDS-operated platform records every API call in a per-user audit log — timestamp, acting access identity, method, and success/error — and exposes it for examination. The audit record is data-minimal by construction (request bodies are not stored), so reviewing activity does not create a second copy of ePHI. Detail: 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. Evidence: internal:hipaa/policies/audit-controls Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy]; basis: integration Define and document your audit-review cadence and who performs it; retain the review records per your retention policy. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy]; basis: integration Define and document your audit-review cadence over the platform-provided log, and who performs it. Retain the review records. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(c)(1) — Integrity — standard Requirement: Implement policies and procedures to protect ePHI from improper alteration or destruction. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-c-1 PRYV PLATFORM: facilitated (mode: primitive) Integrity is multi- layered: write authorization gated by `permissions`, event versioning preserves the prior value on every update, audit pins the (who, when, via which access) attribution, and `bin/backup.js` provides the recovery path if a destruction event needs to be reversed. The standard's overall programmatic obligation is yours; the technical substrate is Pryv's. PLANNED (feature, impact medium): Chained / signed audit log enforces log integrity at the primitive layer HDS: facilitated (effort saved: medium) (mode: primitive) Integrity is layered in the HDS-operated platform: writes are gated by per-stream permissions, updates preserve the prior value through versioning, the audit log pins who-changed-what-when, and operational backups provide a recovery path if a destruction event must be reversed. The overall integrity programme remains the implementer's; the technical substrate is HDS-operated. Detail: 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. Evidence: internal:hipaa/policies/integrity Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: entity Author your integrity policy — change-control, who may alter records, and how destruction is prevented and recovered — over the platform substrate. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: entity Author your integrity policy over the platform substrate: change control, who may alter records, and how destruction is prevented and recovered. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(c)(2) — Mechanism to authenticate ePHI — Addressable Requirement: Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-c-2 PRYV PLATFORM: facilitated (mode: evidence) Event versioning preserves the prior content on every update, so "is this the original?" is a tractable question, compare against the history. The audit row references the access that performed the update, anchoring the change to an authenticated actor. Tamper detection beyond this (e.g., end-to-end content hashing under a customer-held key) is on the implementer or an extension. Detail: Audit-log tamper resistance itself is **voluntarily missing today**: rows are append-only by convention in the audit-write code path, but there is no software-side hash chain or signature. Integrity rests on the operator's filesystem posture (immutable mounts, append-only flags, file-integrity monitoring, out-of-band SIEM forwarding). Future direction: chained / signed audit log (per-row prev_hash + periodic operator-signed checkpoints). Tracked under internal backlog slug `AUDIT-LOG-CHAINING` and `proposals/audit-log-chaining.md`. When shipped, this row moves from `F: Evidence | Low` to `F: Evidence | Med`. PLANNED (feature, impact medium): Chained / signed audit log authenticates audit data (row moves F:Evidence|Low → F:Evidence|Med) HDS: facilitated (effort saved: low) (mode: evidence) Event versioning retains prior content on every update, so "is this the original?" is answerable by comparison against the history, and the audit record anchors each change to an authenticated access identity. Tamper detection beyond this — e.g. cryptographic content hashing under an implementer-held key — remains on the implementer or an extension. Detail: 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. Evidence: internal:hipaa/policies/integrity Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: configurable applies_when: [stores-phi-copy]; basis: integration Decide, per your risk analysis, whether the platform's versioning + audit evidence suffices or whether to add content-integrity verification, and document the addressable decision. IMPLEMENTER [business-associate] coverage: configurable applies_when: [stores-phi-copy]; basis: integration Decide, per your risk analysis, whether the platform's versioning and audit evidence suffices or whether to add content-integrity verification, and document the addressable decision. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(d) — Person or entity authentication — standard Requirement: Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-d PRYV PLATFORM: implemented Authentication is mediated by the access-token primitive: the bearer of a valid token has been authenticated. Strength of that authentication is layered, username + password by default; MFA via `mfa.*` API methods when `services.mfa.mode` is set. Recovery paths preserve account ownership when a second-factor device is lost. Detail: **MFA is pluggable.** The `Service` base class (`components/business/src/mfa/Service.ts`) defines `challenge()` + `verify()` methods; two subclasses ship (`ChallengeVerifyService`, `SingleService`) targeting HTTP-callable external providers (SMS by config default). An operator can plug in any provider matching the challenge/verify shape via `services.mfa` config (Twilio Authy, Auth0 MFA, Duo Web push, …) without writing code, or extend `Service` to implement any in-process method. NIST AAL framing: the achievable AAL depends on which provider is configured. SMS-only is AAL1 under NIST SP 800-63B Rev 3. TOTP + push or WebAuthn-based providers reach AAL2. Reference plugins for in-process TOTP + WebAuthn are tracked under internal backlog slug `MFA-MODERN-METHODS` (matrix-side mirror at `proposals/mfa-modern-methods.md`); the broader OAuth2 auth-stack modernisation arc subsumes this work. MFA is opt-in per operator; once enabled, it can be required at login, at sensitive operations, or both. The MA test series exercises activate / confirm / challenge / verify / deactivate / recover paths. **A second authentication path, OAuth2.** Beyond the token + MFA stack above, Pryv can authenticate delegated apps through a standards-based OAuth2 authorization-code + PKCE flow (`open-pryv.io/components/oauth2/`, shipped in open-pryv.io 2.0.0-rc.8). PKCE is mandatory (S256 only, `code_challenge_methods_supported: ['S256']` in `open-pryv.io/components/oauth2/src/wellKnown.ts`); access tokens are short-lived (`oauth.accessTokenTTL`, default 1 h) and refresh tokens rotate single-use with a sliding TTL bounded by an absolute cap (`oauth.refreshTokenTTL` / `oauth.refreshTokenAbsoluteTTL`). When `oauth.requireAppAccountMfa` is set (default true), an app account must enrol MFA before it can drive the OAuth2 write surface, so the second-factor requirement extends to the delegated-app path. **Sender-constrained tokens (DPoP).** A delegated app may opt into RFC 9449 DPoP: it proves possession of a client-held key on each request, and the token is bound to that key's thumbprint (issued `token_type: DPoP`). A token stolen in transit or from storage is then useless without the private key, it materially strengthens "the entity seeking access is the one claimed" for bearer tokens. Opt-in and additive (Bearer clients are unchanged). The proof's freshness window is `oauth.dpop.clockSkewSeconds` (default 120 s); DEPLOYMENT NOTE: DPoP binds to the client-facing request URI, so a deployment accepting it must sit behind a proxy that overwrites the X-Forwarded-Host / -Proto headers. Server-side landed in open-pryv.io `9a874599`; the client side ships in the `pryv` JS library 3.10.0 (`SignedConnection`, `OAuth2Client` with `dpop: true`). **Operator key revocation.** When a bound key is compromised, you revoke it platform-wide by its RFC 7638 thumbprint (`bin/oauth-client.js revoke-key --yes`): every token bound to the key, including refresh rotations attempted after the revoke, is rejected on all cores within `oauth.dpop.keyRevokeCheckSeconds` (default 30 s), and the token endpoint refuses to mint for it. An advisory per-client key inventory (`list-keys`) shows what a revocation will hit before you run it (open-pryv.io `4c0a5ade`). PLANNED (enhancement, impact medium): Reference MFA plugins (TOTP / WebAuthn) + primitive-catalogue doc surface the pluggability HDS: implemented (effort saved: high) Authentication in the HDS-operated platform is mediated by the access-token primitive: the bearer of a valid token has been authenticated, and no anonymous access to ePHI is possible from the API. HDS has decided and dated its own multi-factor position: MFA is mandatory for HDS workforce and operator access, and available but not mandated for end users. Recovery paths preserve account ownership when a factor is lost. Detail: 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. Evidence: internal:hipaa/policies/authentication Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects]; basis: integration Decide and document your authentication strength (e.g. whether MFA is required, and for which roles or operations). IMPLEMENTER [business-associate] coverage: documented applies_when: [connects]; basis: integration Decide and document your authentication strength over the platform, including whether MFA is required and for which roles or operations. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(e)(1) — Transmission security — standard Requirement: Implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-e-1 PRYV PLATFORM: implemented All Pryv API traffic terminates on TLS 1.3 by default, with certificates issued + auto-renewed via the built-in ACME integration. Inter-core traffic in a multi-core cluster runs over mTLS using a cluster-private CA. There is no plaintext path shipped. Detail: LE certificate replication uses rqlite keyspace `tls-cert/` + `tls-acme-account`; rotation triggers `https.Server.setSecureContext` via cluster IPC for live key swap without downtime. The cluster CA lives outside the LE chain, operator-rooted, used only between cores. **Webhook delivery is signal-only.** Outbound webhook POSTs from Pryv carry a notification that something changed, not the changed data itself. Receivers fetch the current state via authenticated GET back to Pryv (same access-token-protected paths as any other read). No PHI / PII / tokens transit the webhook surface; the transmission-security attack surface narrows accordingly. See `context/webhooks-signal-only.md` for the full design rationale + operational caveats (TLS-on- delivery, retry semantics, poison-pill protection). **Credential hand-off between parties.** TLS protects the pipe; the shared-secrets primitive (`open-pryv.io/components/shared-secrets/`) protects the credential travelling over it. Handing an access credential to a counterparty (e.g. inviting a care-team member) used to mean a URL-embedded token that lingers in browser history, referrer headers, and intermediary access logs after the TLS session ends. Instead, the counterparty receives a one-time random key: redeemable exactly once, mandatory expiry, hash-only server-side storage (the SHA-256 of the key's random half), optional passphrase / HMAC gate on redemption. An intercepted or logged link therefore never carries a live, replayable credential to ePHI. Expiry is enforced when someone reaches for the secret rather than by a background sweeper, so plan your own deletion pass if ePHI retention rules require expired payloads to be gone by a fixed deadline. HDS: implemented (effort saved: high) All API traffic to the HDS-operated platform is carried over TLS by default; there is no plaintext path served. Transmission security is therefore a technical property of every connection rather than an optional add-on, in both the US and Switzerland regions. Detail: 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. Evidence: internal:hipaa/policies/transmission-security Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Ensure your client and any onward integration hops you control transmit ePHI only over TLS; document the transmission-security boundary. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Ensure any transmission path you operate carries ePHI only over TLS, and document the transmission-security boundary. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(e)(2)(i) — Integrity controls — Addressable Requirement: Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-e-2-i PRYV PLATFORM: implemented TLS 1.3 provides cryptographic integrity (AEAD) on every byte in transit. End-to-end transmission integrity is therefore a property of the connection, modification in transit is cryptographically detectable. Endpoint-to-endpoint integrity across multiple hops (e.g., proxy chains) requires the implementer's chain to preserve this property. HDS: implemented (effort saved: high) TLS provides cryptographic integrity on every byte in transit, so modification of ePHI on the connection to the HDS-operated platform is cryptographically detectable. End-to-end integrity across any additional hops depends on the implementer's chain preserving the same property. Detail: 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. Evidence: internal:hipaa/policies/transmission-security Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Preserve transmission integrity across any hops you operate, and document the addressable decision. IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Preserve transmission integrity across any hops you operate, and document the addressable decision. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.312(e)(2)(ii) — Encryption — Addressable (transmission) Requirement: Implement a mechanism to encrypt ePHI whenever deemed appropriate. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-312-e-2-ii PRYV PLATFORM: implemented TLS 1.3 in transit is default-on via the built-in ACME integration; mTLS between cores is the inter-node default once a cluster is bootstrapped. "Whenever deemed appropriate", Pryv's default for ePHI transit is: always. Detail: Operators running behind a TLS-terminating reverse proxy can opt `letsEncrypt.enabled: false` and let the proxy hold the certs; the core then serves plain HTTP only on its loopback. The TLS requirement holds at the transmission boundary, wherever the operator chooses to place that boundary. HDS: implemented (effort saved: high) Encryption of ePHI in transit is default-on: the HDS-operated platform serves only TLS-encrypted endpoints, so the "whenever deemed appropriate" judgement is resolved to "always" for transmission. This row covers transmission only; at-rest encryption is addressed under §164.312(a)(2)(iv). Detail: 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). Evidence: internal:hipaa/policies/transmission-security Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Document that transmission encryption is in force; separately address at-rest encryption per §164.312(a)(2)(iv). IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Record that transmission encryption is in force, and address at-rest encryption separately under 164.312(a)(2)(iv). IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.314(a)(1) — Business associate contracts — Organizational requirement Requirement: A covered entity is not in compliance unless it has obtained satisfactory assurances, via a written contract, that the business associate will appropriately safeguard the ePHI it creates, receives, maintains, or transmits on the covered entity's behalf. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-314-a-1 PRYV PLATFORM: facilitated (mode: storage) The BAA itself is a contract, the covered entity drafts it with legal counsel. What Pryv contributes when you operate as a business associate: the audit log makes "implement administrative, physical and technical safeguards" (§164.314(a)(2)(i)(A)) auditable per the BAA's specified terms; the access primitive bounds which subjects + which streams the BA may touch; CMC's cross-platform consent flow gives a structured channel for the §164.314(a)(2)(i)(C) breach-notification pipe between BA and CE. HDS: facilitated (effort saved: medium) (mode: evidence) HDS provides a Business Associate Agreement template and the technical assurances (audit, access control, monitoring, regional residency) that back it, and signs BAAs with its own subcontractors. The contract itself is executed between the parties. Detail: 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. Evidence: internal:hipaa/registers/baa-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Execute a business associate agreement with every business associate you engage, before any ePHI reaches them, and keep each on file. HDS is not one of them: an individual granting you access to their own vault is consent, not delegation. Templates to sign: baa IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Execute back-to-back agreements with any downstream subcontractor you engage. No agreement with HDS is needed for vault access: it flows from the individual's consent, not from you instructing HDS. Templates to sign: baa, subcontractor IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.314(a)(2)(i)(A) — Business associate contract — implement reasonable and appropriate safeguards Requirement: The business associate contract must require the business associate to implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the ePHI it handles on the covered entity's behalf. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-314-a-2-i-a PRYV PLATFORM: facilitated (mode: infrastructure) The BAA's "reasonable and appropriate safeguards" obligation is satisfied by the technical-safeguards programme already enumerated across §164.308 + §164.310 + §164.312. The BA cites the relevant Pryv-implemented rows when populating their BAA exhibit. Mapping this Article to the existing technical-safeguards rows is the `derives_from` chain. HDS: facilitated (effort saved: high) (mode: evidence) The safeguards an HDS business associate agreement would commit to are the same technical and administrative controls enumerated across the §164.308, §164.310 and §164.312 rows of this matrix, and the template cites that programme so an implementer can populate its safeguards exhibit by reference. The same controls back the subcontractor agreements HDS has actually executed downstream. Detail: 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. Evidence: internal:hipaa/registers/baa-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Confirm that the BAA's safeguards clause reflects the controls you rely on, and retain the safeguards exhibit with the executed contract. Templates to sign: baa IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Ensure the safeguards you commit to your covered entity are matched by the controls you and your downstream processors actually operate. Templates to sign: baa, subcontractor IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.314(a)(2)(i)(C) — Business associate contract — report security incidents Requirement: The business associate contract must require the business associate to report to the covered entity any security incident of which it becomes aware, including breaches of unsecured ePHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-314-a-2-i-c PRYV PLATFORM: facilitated (mode: evidence) Detection of a security incident is the BA's operational concern (audit-log review + observability). Reporting to the CE is the contractual flow. Pryv's CMC plugin provides a structured cross-account messaging substrate when both sides run Pryv, otherwise the report channel is email / API / portal at the BA's choice. The audit log supplies the forensic evidence the report cites. HDS: facilitated (effort saved: medium) (mode: evidence) An HDS business associate agreement commits HDS to notifying the counterparty of security incidents affecting their ePHI, and HDS's monitoring and incident-response programme supplies the detection and forensic evidence behind that obligation. No upstream agreement is in force today, so what operates now is HDS's own incident procedure together with the reporting its downstream subcontractor agreements require. Detail: 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. Evidence: internal:hipaa/registers/baa-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Ensure each agreement with your own business associates specifies the incident-report channel and timing, and integrate what you receive into your own breach-assessment procedure. Templates to sign: baa IMPLEMENTER [business-associate] coverage: documented applies_when: [connects, stores-phi-copy, third-parties]; basis: integration Flow the incident-report obligation through to your covered entity and down to your subcontractors. Templates to sign: baa, subcontractor IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.314(a)(2)(ii)(B) — Business associate contract — extend safeguards to subcontractors Requirement: Where applicable, the business associate must ensure that any subcontractors that create, receive, maintain, or transmit ePHI on its behalf agree, via a written contract, to comply with the applicable Security Rule requirements. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-314-a-2-ii-b PRYV PLATFORM: out-of-scope Subcontracting chains are contractual; no software role. The only built-in subprocessor Pryv-the-software carries is the observability-provider adapter (default disabled); when enabled, the BA's subcontractor list adds the observability provider as a sub-processor under both HIPAA-Security §164.314(a)(2)(ii)(B) and GDPR Art.28(4). HDS: facilitated (effort saved: medium) (mode: evidence) HDS executes back-to-back agreements with each subcontractor that may touch ePHI and tracks them in its BAA register, so the flow-down exists wherever a BAA is in force. HDS also provides the implementer a subcontractor agreement template to flow the same obligations down their own chain. Detail: 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. Evidence: internal:hipaa/registers/baa-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [third-parties]; basis: integration Review HDS's subprocessor list as part of your vendor due diligence. Templates to sign: baa IMPLEMENTER [business-associate] coverage: documented applies_when: [third-parties]; basis: integration Execute written agreements with each of your own downstream subcontractors that handle ePHI, flowing the Security Rule obligations through. Templates to sign: subcontractor, subprocessor IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.316(a) — Policies and procedures — standard Requirement: Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, and other requirements of the Security Rule. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-316-a PRYV PLATFORM: out-of-scope The policies-and-procedures programme is an organizational artefact owned by the covered entity / business associate's security officer. Pryv has no software role in drafting them. Pryv-side documentation (this matrix, CHANGELOGs, the QMS workstream) feeds the operator's policy work but doesn't substitute for it. HDS: documented (effort saved: medium) HDS maintains its own written information-security policy set covering the Security Rule safeguards for the systems it operates. This governs HDS's role as operator; the implementer keeps its own policy programme for the parts it controls. Detail: 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. Evidence: internal:hipaa/policies/information-security-policy Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Maintain your own reasonable and appropriate policies and procedures for the parts of the system and workflow you control. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Maintain your own Security Rule policy set covering your handling of ePHI. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.316(b)(1) — Documentation — Required Requirement: Maintain the policies and procedures implemented to comply with the Security Rule in written or electronic form, and maintain a written or electronic record of any action, activity, or assessment the subpart requires to be documented. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-316-b-1 PRYV PLATFORM: facilitated (mode: storage) Where the required record is operational (activity logs, assessment outputs), Pryv events on a designated `compliance/*` stream carry the documentation alongside the audit log's automatic operational record. Event versioning preserves the change history of policies-as-data; backup-restore preserves them across the §164.316(b)(2) retention window. HDS: documented (effort saved: medium) HDS keeps its security policies, procedures, registers and assessment outputs in durable written form under a documentation-management policy. Required activity records are retained alongside the audit trail of the systems HDS operates. Detail: 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. Evidence: internal:hipaa/policies/documentation-and-retention Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Keep your own policies, procedures and required activity records in written or electronic form. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Maintain written documentation of your Security Rule compliance and the activities the subpart requires you to record. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.316(b)(2)(i) — Documentation — time limit — Required Requirement: Retain the documentation required by §164.316(b)(1) for six years from the date of its creation or the date when it last was in effect, whichever is later. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-316-b-2-i PRYV PLATFORM: facilitated (mode: storage) Six-year is a **minimum** retention period, not a maximum (the statute says "retain … for 6 years"; covered entities may retain indefinitely). Pryv's audit log persists by default; retention beyond the minimum + any operational pruning are operator-driven choices (operator schedules archival to cold storage per their policy). `bin/backup.js` produces the artefact the §164.316 retention rule attaches to. Detail: **Minimum 6-year retention is the regulatory floor; there is no max.** Pryv never *requires* destruction at the 6-year mark, operators commonly retain indefinitely under GDPR Art.17(3)(b) "compliance with a legal obligation" lawful basis (the §164.316 retention itself, or sectoral regs) or Art.17(3)(e) "legal claims". The pressure to prune is operational (storage cost / DB performance over 10B-row scales), not regulatory. **Tiering pattern for long-running deployments**: the audit log is exposed via the `@pryv/datastore` abstraction (`auditDataStore` registered as `_audit` in the Mall; `components/audit/src/datastore/auditDataStore.ts`). An operator wanting to tier hot recent rows + cold archived rows writes a custom `auditStorage` engine plugin (per `storages/engines/*/manifest.json`) that routes writes to a hot tier + reads to a union view across hot + cold. End users see one continuous log via `audit.getLogs`; the storage backing it is the operator's choice. Full pattern detail in `context/audit-archival-via-custom-datastore.md`. **Cascade with the Q8 erasure setting** (shipped 2026-05-27, open-pryv.io master `405b3a1`): the `audit.onUserDelete: keep` operator setting is the HIPAA-friendly path when a covered entity deletes a subject's account while needing to retain the audit. The retention obligation runs under a lawful basis separate from the deletion itself (HIPAA Privacy Rule §164.530(j) anchors documentation-retention independently of subject account state). Audit erasure on `auth.delete` now converges across engines (SQLite + PostgreSQL, open-pryv.io `891090d` + `853e1cb`): with `audit.onUserDelete: erase` (default), both engines reach zero audit rows for the deleted subject. With `keep`, the PG path retains rows as designed; the SQLite path still has the parent `deleteAuditData` filesystem-wipe step running afterwards (known caveat, operators wanting `keep` on SQLite need either a PG audit migration or a follow-up teaching `deleteAuditData` to skip when `mode === 'keep'`). HDS: documented (effort saved: medium) HDS retains its security documentation and required records for at least six years under its documentation-and-retention policy, treating six years as a regulatory floor rather than a destruction deadline. Detail: 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. Evidence: internal:hipaa/policies/documentation-and-retention Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: [stores-phi-copy]; basis: integration Retain your own Security Rule documentation for at least six years from creation or last-effective date. IMPLEMENTER [business-associate] coverage: documented applies_when: [stores-phi-copy]; basis: integration Apply the six-year minimum retention to your own policies, procedures and required records. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## hipaa-security 164.316(b)(2)(iii) — Documentation — updates — Required Requirement: Review documentation periodically, and update it as needed in response to environmental or operational changes affecting the security of the ePHI. Anchor: https://compliance.datasafe.dev/hipaa.html#req-164-316-b-2-iii PRYV PLATFORM: facilitated (mode: evidence) Periodic review cadence is the operator's procedure. Pryv's contribution: when policies- as-data are stored as events on a `compliance/policies/*` stream, the event-version chain shows when each policy was last reviewed and what changed; audit log shows who-reviewed- what. HDS: documented (effort saved: medium) HDS reviews its security documentation on a defined periodic cadence and updates it in response to changes in its environment or operations. Review dates and changes are tracked so the documentation's currency is demonstrable. Detail: 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. Evidence: internal:hipaa/policies/documentation-and-retention Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [covered-entity] coverage: documented applies_when: always; basis: entity Review and update your own documentation periodically and in response to operational or environmental changes. IMPLEMENTER [business-associate] coverage: documented applies_when: always; basis: entity Keep your Security Rule documentation current through periodic and event-driven reviews. IMPLEMENTER [individual] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA # SOC 2 — AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) (soc2) standard · United States (AICPA) · Trust Services Criteria (2017), with revised points of focus (2022) · regions: us, ch Official text: https://www.aicpa-cima.com/resources/landing/trust-services-criteria HDS's own position on SOC 2: - vault: HDS is service-organization. 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. External assurance: none. HDS holds NO SOC 2 report. There is no Type I and no Type II, no audit period has been defined and no CPA firm has been engaged. Nothing on this site should be read as a SOC 2 opinion. Certificates HDS relies on but does NOT hold: AWS SOC 2 (hosting layer only, as a subservice organisation) Evidence: 45 of 61 requirements answered from approved HDS documentation (61 cite internal evidence), as of 2026-09-10. 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. Known gaps in HDS's own position: - [high] No SOC 2 examination has been engaged, so there is no report to give a user entity that asks for one. - [medium] A written change-management process with ticketed approvals, per-change test evidence and rollback is drafted but not operating. (refs: CC8.1) - [medium] A formal vendor-management programme with scored risk tiers and scheduled re-assessment is drafted but not operating. (refs: 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. (refs: PI1.5) ## soc2 CC1.1 — CC1.1 — Commitment to integrity and ethical values Requirement: The service organization demonstrates a commitment to integrity and ethical values as a foundation for its system of internal control. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc1-1 PRYV PLATFORM: out-of-scope Integrity + ethics are a management-and-culture matter. Pryv has no software role at the values / code-of-conduct layer; your audit log can later evidence whether workforce behaviour matched the stated values, but the commitment itself is yours to make and document. HDS: documented (effort saved: low) Integrity and ethical values are a matter of organizational culture, not software. HDS maintains a written code of conduct and information-security policy that set the ethical baseline for its own workforce operating the platform; the service organization building on HDS sets and documents its own. The platform contributes only after the fact: the per-user audit log can evidence whether workforce behaviour matched the stated values. Detail: HDS holds this as an operator governance artefact rather than a platform feature. Its commitment to integrity is expressed in a documented code of conduct and the umbrella information-security policy referenced throughout this matrix; both are reviewed periodically. A partner attesting under SOC 2 cannot inherit HDS's culture controls — they author their own — but may cite the audit log as the substrate that holds individuals accountable to whatever ethical baseline they set. Evidence: internal:hipaa/policies/information-security-policy Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Establish and document your own code of conduct and ethical-values baseline; this is a management and culture obligation HDS cannot carry for you. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Maintain your own integrity and ethics programme for the workforce that operates any downstream service. ## soc2 CC1.2 — CC1.2 — Board independence and oversight Requirement: The board of directors operates independently of management and oversees the development and performance of internal control. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc1-2 PRYV PLATFORM: out-of-scope Board governance is organizational. No software contribution; this matrix + the audit log feed the oversight pack the board reviews, but the oversight function is yours. HDS: documented (effort saved: low) Board governance and oversight are organizational structures with no software role. HDS documents its own governance and oversight arrangements internally; the service organization documents its own board's independence and oversight function. This matrix and the audit log can feed the oversight pack a board reviews, but the oversight function itself is a governance obligation. Detail: HDS treats board-level oversight as an operator governance artefact, held privately and available on request. The arrangements are written down; the formal, minuted oversight review of the control environment has not yet run its first cycle, and HDS records that as the outstanding half rather than presenting the arrangement as an operating control. Where HDS operates the platform, this matrix doubles as a control inventory the partner's own board can review, and the audit log supplies control-operation evidence. The independence and oversight obligation cannot be inherited; each attesting organization carries its own. Evidence: internal:soc2/policies/governance-and-oversight IMPLEMENTER [service-organization] coverage: documented applies_when: always Document your own board's independence and its oversight of internal control; a governance obligation outside the platform. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Document the equivalent oversight arrangements for your own organization. ## soc2 CC1.3 — CC1.3 — Management structures, reporting lines, and authorities Requirement: Management, with board oversight, establishes structures, reporting lines, and appropriate authorities and responsibilities in pursuit of the entity's objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc1-3 PRYV PLATFORM: out-of-scope Org structure + authority assignment are management artefacts. Pryv enforces the *technical* half of "appropriate authorities" once you've decided them (see CC6.3 least-privilege), but the reporting-line design itself is yours. HDS: documented (effort saved: low) Organizational structure and authority assignment are management artefacts. HDS documents the reporting lines and authorities for its own platform operation, including the named security official accountable for the programme. The platform enforces the technical half of "appropriate authorities" once they are decided (least-privilege access, see CC6.3), but the structure design itself is management work. Detail: HDS holds its own management structure, reporting lines and authority assignments as documented operator artefacts. The technical realisation of authority — who may exercise which permissions — is carried by the access-token model and recorded in the audit log; the design of the reporting lines and the assignment of responsibilities are governance decisions each attesting organization makes for itself. Evidence: internal:hipaa/policies/access-control, internal:soc2/policies/governance-and-oversight IMPLEMENTER [service-organization] coverage: documented applies_when: always Define and document your own reporting lines and authority assignments; map the resulting authorities onto least-privilege access grants. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Document your own management structure and authorities for the service you operate downstream. ## soc2 CC1.4 — CC1.4 — Commitment to competence Requirement: The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc1-4 PRYV PLATFORM: out-of-scope Hiring + training + retention is an HR programme. No software role. HDS: documented (effort saved: low) Hiring, training and retention of competent staff is an HR programme with no software role. HDS runs and documents its own competence programme for the workforce operating the platform: training is continuous, certifications are tracked in a completion register, and overdue members are flagged. What is still being assembled is the HDS-specific curriculum material and the outstanding policy acknowledgements. The service organization runs its own programme. Detail: HDS treats workforce competence as an operator governance artefact. Its documented programme covers role-relevant skills for staff operating the platform and runs continuously against a completion register rather than as isolated certificates. The platform makes no contribution at this layer. HDS states its residual gaps plainly, the curriculum material and the outstanding acknowledgements, and addresses them as they arise; a partner attesting under SOC 2 maintains its own competence programme. Evidence: internal:soc2/policies/workforce-competence PLANNED (procedure, impact medium): The workforce-training procedure is approved and the completion register holds dated third-party certifications for every workforce member, with expiry reminders wired to the internal tasks board. What remains is the HDS-specific curriculum, the recorded acknowledgements, and letting the monthly cadence run a first full cycle: no per-occurrence execution record has been filed yet. IMPLEMENTER [service-organization] coverage: documented applies_when: always Run and document your own hiring, training and competence programme; HDS cannot carry this for you. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Maintain a competence programme for your own downstream workforce. ## soc2 CC1.5 — CC1.5 — Accountability for internal control responsibilities Requirement: The entity holds individuals accountable for their internal control responsibilities in pursuit of its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc1-5 PRYV PLATFORM: facilitated (mode: evidence) Pryv gives you the technical accountability substrate: every API call is attributable to an access (accessId + accessSerial) in the per-user audit log, so "who did what, when" is recoverable when you need to hold an individual to account. Defining the responsibilities and the consequence process is your management activity; Pryv supplies the evidence trail. HDS: facilitated (effort saved: medium) (mode: evidence) The platform HDS operates supplies the technical accountability substrate: every API call is attributable to a specific access identity in the per-user audit log, so "who did what, when" is recoverable when an individual must be held to account. HDS layers its own sanction and accountability policy on top and documents it; defining responsibilities and the consequence process is each organization's management activity. Detail: Accountability has two halves. The evidence half is platform-native — the audit log attributes each action to an access identity, giving an objective record against which responsibilities can be enforced. The policy half (which responsibilities, what consequences) is governance; HDS documents the accountability and sanction policy it operates for its own workforce. A partner inherits the audit substrate but authors its own accountability framework. Evidence: internal:hipaa/policies/audit-controls, internal:soc2/policies/accountability-and-sanctions IMPLEMENTER [service-organization] coverage: documented applies_when: always Define the internal-control responsibilities and the consequence process; use the per-user audit log as the accountability evidence trail. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Hold your own workforce accountable using the audit substrate and your own sanction policy. ## soc2 CC2.1 — CC2.1 — Quality information to support internal control Requirement: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc2-1 PRYV PLATFORM: facilitated (mode: evidence) Pryv produces two streams of control-relevant information: the per-user audit log (application-level activity, attributable to an access) and observability metrics (operational + security KPIs via the pluggable provider). What you monitor and how you act on it is your programme; Pryv supplies the quality data. HDS: facilitated (effort saved: medium) (mode: evidence) The platform produces two streams of control-relevant information that HDS operates: the per-user audit log (application-level activity, attributable to an access identity) and operational monitoring (security and operational KPIs across every data-residency option). What to monitor and how to act on it is each organization's programme; HDS supplies the quality data and runs its own monitoring over the platform. Detail: Quality information for internal control comes from the audit log and HDS's operational monitoring, which is wired end to end with alerting before any component is treated as in production. HDS documents the monitoring it operates. A partner consumes the same substrate to feed its own control-monitoring process and defines its own thresholds and review cadence. Evidence: internal:hipaa/policies/audit-controls, internal:soc2/procedures/control-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define what control-relevant information you collect and how you act on it, drawing on the audit log and monitoring substrate HDS exposes. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate your own monitoring and information-quality process over the substrate you run downstream. ## soc2 CC2.2 — CC2.2 — Internal communication of objectives and responsibilities Requirement: The entity internally communicates information, including objectives and responsibilities for internal control, needed to support its functioning. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc2-2 PRYV PLATFORM: out-of-scope Internal communication of objectives is a management activity. No software role at the communication-content layer. HDS: documented (effort saved: low) Internal communication of objectives is a management activity with no software role at the communication-content layer. HDS documents how it communicates security objectives and responsibilities to its own workforce; the service organization runs its own internal-communication programme. Detail: HDS holds this as an operator governance artefact: its information-security policy and internal communication channels convey control responsibilities to staff. The platform contributes nothing at the content layer. Each attesting organization authors and operates its own internal communication of objectives and responsibilities. Evidence: internal:hipaa/policies/information-security-policy Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Communicate internal-control objectives and responsibilities to your own workforce; a management obligation outside the platform. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Communicate the equivalent objectives and responsibilities to your own downstream workforce. ## soc2 CC2.3 — CC2.3 — External communication on internal control matters Requirement: The entity communicates with external parties about matters affecting the functioning of internal control. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc2-3 PRYV PLATFORM: facilitated (mode: awareness) For the slice of external communication that concerns the Pryv platform itself, open-pryv.io's public release process is the channel: tagged releases, CHANGELOG-v2 + CHANGELOG-v2-back, and (when shipped) the vulnerability-disclosure programme. You layer your own customer / subprocessor / auditor communications on top. HDS: facilitated (effort saved: low) (mode: awareness) For the slice of external communication that concerns the platform itself, the public release process is the channel: tagged releases and published change notes communicate what changed in the substrate. HDS layers its own external-communication programme (customer, subprocessor and auditor communications) on top and documents it. The service organization runs its own. Detail: External communication about internal control has a platform half and an operator half. The platform half rides on the public open-source release process. The operator half — how HDS communicates security and incident matters to its customers and subprocessors — is documented as an operator artefact and backed by the subprocessor register. A partner attesting under SOC 2 authors its own external-communication programme. Evidence: internal:hipaa/policies/information-security-policy, internal:hipaa/registers/subprocessor-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Author your own external communications about internal control to customers, subprocessors, regulators and auditors. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Communicate control matters to the parties you serve and to your own upstream service organization. ## soc2 CC3.1 — CC3.1 — Objectives specified with sufficient clarity Requirement: The entity specifies objectives with enough clarity to enable the identification and assessment of risks relating to them. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc3-1 PRYV PLATFORM: out-of-scope Objective-setting is your management exercise. Pryv has no role in authoring objectives; the matrix supports the downstream risk-to-control mapping once your objectives exist. HDS: documented (effort saved: low) Objective-setting is a management exercise; the platform has no role in authoring objectives. HDS documents the security and availability objectives it sets for its own platform operation. This matrix supports the downstream risk-to-control mapping once an organization's objectives exist. Detail: HDS holds its own service objectives (confidentiality, integrity, availability targets for the operated platform) as documented operator artefacts that anchor its risk assessment. A partner cannot inherit these — it specifies its own objectives — but can use this matrix to map identified risks onto the platform controls that address them. Evidence: internal:soc2/policies/system-description Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Specify and document your own service objectives with enough clarity to drive your risk assessment. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Specify your own objectives for the service you operate downstream. ## soc2 CC3.2 — CC3.2 — Identification and analysis of risk Requirement: The entity identifies risks to the achievement of its objectives across the entity and analyzes them as a basis for deciding how they should be managed. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc3-2 PRYV PLATFORM: facilitated (mode: evidence) Your risk-assessment methodology and the specific findings are yours. Pryv contributes the inventory of technical controls (this matrix, particularly the CC6 access + CC6.6/6.7 boundary + cryptography rows), when you identify a confidentiality / integrity / availability risk, the matrix surfaces which Pryv primitive addresses it, so control applicability is mechanical rather than judgemental. HDS: documented (effort saved: medium) A formal risk assessment is each organization's own methodology and findings. HDS has an approved security risk analysis covering the platform, all hosting regions and the access paths to them, with a treatment register keyed to it. What has not been run is the SOC 2-specific half: CC3.2 reaches wider than ePHI security, to risks against the other trust-services objectives, and HDS states that gap plainly rather than presenting the security analysis as the whole. What HDS contributes to an attesting organization is the inventory of technical controls (this matrix, especially the CC6 access and CC6.6/6.7 boundary and cryptography rows), so when a confidentiality, integrity or availability risk is identified, the control that addresses it is mechanical to locate. Detail: HDS treats its own risk assessment as an operator obligation in progress and states the gap plainly rather than claiming a completed assessment. Its contribution to a partner's risk assessment is the control inventory in this matrix plus the audit and monitoring substrate that surfaces emerging risk signals. The risk-assessment methodology and the specific findings are each attesting organization's own. Evidence: internal:soc2/procedures/risk-assessment PLANNED (doc, impact medium): The formal risk analysis is conducted, rated and approved for the security objective. Extending it to the non-security trust-services objectives (availability, confidentiality, processing integrity, privacy) is the tracked remainder; the fraud consideration is carried at CC3.3. IMPLEMENTER [service-organization] coverage: documented applies_when: always Conduct and document your own risk assessment; use this matrix to map identified risks onto the platform controls that mitigate them. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Conduct your own risk assessment for the service you operate downstream. ## soc2 CC3.3 — CC3.3 — Consideration of the potential for fraud Requirement: The entity considers the potential for fraud when assessing risks to the achievement of its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc3-3 PRYV PLATFORM: facilitated (mode: evidence) Pryv's audit log + observability metrics are the detection substrate for insider-misuse and anomalous-access fraud scenarios (every access is attributable; unusual read/write patterns surface). The fraud-risk analysis itself, which scenarios matter, what thresholds trigger review, is your assessment. HDS: facilitated (effort saved: low) (mode: evidence) The audit log and operational monitoring are the detection substrate for insider-misuse and anomalous-access fraud scenarios — every access is attributable, and unusual read or write patterns surface. HDS operates this substrate; the fraud-risk analysis itself (which scenarios matter, what thresholds trigger review) is each organization's assessment. Detail: HDS contributes the technical means to detect the fraud scenarios an assessment identifies: attributable audit records and anomaly signals from monitoring. The analytical step, deciding which fraud risks are in scope and how to respond, is governance. HDS's approved security risk analysis does not assess the potential for fraud, which is a wider question than ePHI security, so that consideration is the outstanding half here. A partner runs its own fraud-risk analysis over the same substrate. Evidence: internal:hipaa/policies/audit-controls, internal:soc2/procedures/risk-assessment IMPLEMENTER [service-organization] coverage: documented applies_when: always Analyze fraud risk as part of your risk assessment; use the audit log and monitoring as the detection substrate for the scenarios you identify. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Consider fraud risk for the service you operate downstream. ## soc2 CC3.4 — CC3.4 — Identification and assessment of changes affecting internal control Requirement: The entity identifies and assesses changes that could significantly affect its system of internal control. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc3-4 PRYV PLATFORM: facilitated (mode: evidence) For changes to the Pryv platform, open-pryv.io's CHANGELOGs + tagged releases announce what changed; the audit log shows when config-driven behaviour changed observably in your deployment. The change-impact assessment process is yours. HDS: facilitated (effort saved: low) (mode: evidence) For changes to the platform substrate, the public release notes announce what changed, and the audit log shows when config-driven behaviour changed observably in a deployment. HDS assesses substrate changes as part of its own operations. The change-impact assessment process for an organization's wider control system is its own. Detail: Change identification on the platform half is supported by published change notes and the audit log's record of observable behaviour change. HDS folds these into its own change handling. A partner uses the same signals to feed its change-impact assessment over its broader control system, which it authors itself. HDS's own formalised change-management programme is still being matured (see CC8.1). Evidence: internal:hipaa/policies/audit-controls, internal:soc2/policies/change-management IMPLEMENTER [service-organization] coverage: documented applies_when: always Identify and assess changes affecting your control system; use platform release notes and the audit log as inputs. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Assess control-affecting changes in the service you operate downstream. ## soc2 CC4.1 — CC4.1 — Ongoing and separate evaluations Requirement: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc4-1 PRYV PLATFORM: facilitated (mode: evidence) Pryv supplies the data an ongoing evaluation samples: the audit log evidences control-effectiveness (e.g., that access scoping actually blocks out-of-scope reads), observability evidences operational health. You define the evaluation cadence and the sampling method. HDS: facilitated (effort saved: medium) (mode: evidence) The platform supplies the data an ongoing evaluation samples: the audit log evidences control effectiveness (for instance that access scoping actually blocks out-of-scope reads), and operational monitoring evidences operational health. HDS has defined its own periodic evaluation over the platform and approved the procedure, but no cycle has completed yet. The evaluation cadence and sampling method for an organization's own controls are its own. Detail: HDS's periodic evaluation is designed to draw on audit samples, monitoring data and this matrix as the control inventory, on an annual cadence; the first full cycle is still to run, so the evaluation half is defined rather than evidenced. A partner consumes the same substrate to sample its own controls and defines its own evaluation programme. This matrix doubles as the control inventory an evaluation assesses against. Evidence: internal:hipaa/procedures/periodic-evaluation, internal:soc2/procedures/control-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define and run your own ongoing and separate evaluations of internal control, sampling the audit and monitoring substrate HDS exposes. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Evaluate the controls of the service you operate downstream. ## soc2 CC4.2 — CC4.2 — Evaluation and communication of deficiencies Requirement: The entity evaluates and communicates internal-control deficiencies in a timely manner to the parties responsible for taking corrective action. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc4-2 PRYV PLATFORM: facilitated (mode: evidence) Pryv-side deficiency signals (audit anomalies, observability alerts) feed your deficiency-tracking process. CAPA-style records can themselves ride on Pryv events on a dedicated stream. The evaluation + communication workflow is your procedure. HDS: facilitated (effort saved: low) (mode: evidence) Deficiency signals from the platform side — audit anomalies, monitoring alerts — feed a deficiency-tracking process. HDS operates its own deficiency-evaluation and corrective-action flow and documents it; corrective records can themselves ride on the platform as events on a dedicated stream. The evaluation and communication workflow is each organization's procedure. Detail: HDS runs a documented process for evaluating and communicating deficiencies it observes in its own operation, fed by audit and monitoring signals and tied to its incident procedure. The periodic-evaluation half of that chain is defined but has not yet run a cycle, so deficiencies surface today through incidents and monitoring rather than through a completed evaluation. A partner authors its own deficiency workflow over the same substrate. The platform can host the corrective-action records themselves as attributable events. Evidence: internal:hipaa/procedures/periodic-evaluation, internal:soc2/procedures/control-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define how you evaluate, track and communicate control deficiencies and their corrective actions. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate your own deficiency-tracking and communication process downstream. ## soc2 CC5.1 — CC5.1 — Selection and development of control activities Requirement: The entity selects and develops control activities that contribute to mitigating risks to the achievement of objectives to acceptable levels. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc5-1 PRYV PLATFORM: facilitated (mode: primitive) Several of your control activities ARE Pryv primitives: permission-scoped access tokens (purpose limitation), system streams (privileged-data isolation), encryption of operator secrets at rest. You select which to deploy against which risk; Pryv provides the activities ready-made rather than as something you build. HDS: facilitated (effort saved: medium) (mode: primitive) Several control activities are platform primitives HDS operates ready-made: permission-scoped access tokens (purpose limitation), system-level isolation of privileged data, and encryption of operator secrets at rest. An organization selects which to deploy against which risk; HDS provides the activities as shipped controls rather than something to build, and documents the configuration it runs. Detail: The control-activity selection step is governance, but a meaningful subset of the activities themselves are platform-native: least-privilege access grants, privileged-namespace isolation, and at-rest encryption of operator secrets. HDS operates these and documents its access-control configuration. A partner selects and operates the activities appropriate to its risk assessment over the same primitives. Evidence: internal:hipaa/policies/access-control, internal:soc2/procedures/control-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Select the control activities appropriate to your risks; deploy the platform primitives (scoped access, isolation, secret encryption) that implement them. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Select and operate control activities for the service you run downstream. ## soc2 CC5.2 — CC5.2 — General control activities over technology Requirement: The entity selects and develops general control activities over technology to support the achievement of its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc5-2 PRYV PLATFORM: facilitated (mode: primitive) The technology general controls SOC 2 examines, logical access, authentication, encryption in transit + at rest for secrets, audit logging, secure inter-core transport, are shipped Pryv primitives, enforced at the API surface rather than left to your configuration discipline. The CC6 + CC7 rows below detail each. Your role is selecting and operating them. HDS: implemented (effort saved: high) The technology general controls SOC 2 examines — logical access, authentication, encryption in transit, audit logging, secure inter-core transport — are shipped platform controls HDS operates, enforced at the API surface rather than left to configuration discipline. The CC6 and CC7 rows detail each. An organization's role is selecting and operating them; the mechanisms are in place. Detail: General IT controls are where the platform contribution is strongest: access control and authentication are enforced on every request, transmission is TLS by default, the audit log is always-on, and inter-core transport is mutually authenticated. HDS operates this stack across every data-residency option. At-rest encryption of event data is in force at the hosting layer in every region (full-volume encryption, since 2026-06-26; see CC6.7 for the provider-managed-key residual). A partner selects, configures and operates these controls; it does not build them. Evidence: internal:hipaa/policies/access-control, internal:hipaa/policies/audit-controls, internal:hipaa/policies/transmission-security Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Select, configure and operate the platform general IT controls; document the configuration and weigh the provider-managed-key at-rest residual in your risk analysis. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate equivalent general IT controls for the service you run downstream. ## soc2 CC5.3 — CC5.3 — Deployment of control activities through policies and procedures Requirement: The entity deploys control activities through policies that establish what is expected and procedures that put those policies into action. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc5-3 PRYV PLATFORM: out-of-scope Policy + procedure authoring is your editorial work. Pryv enforces what the policies decide (access rules, encryption), but the policy text and the operating procedures are yours. HDS: documented (effort saved: medium) Policy and procedure authoring is editorial governance work. HDS maintains its own information-security policy set and the operating procedures that put it into action over the platform; the platform enforces what the policies decide (access rules, encryption in transit), but the policy text and procedures are an organization's own. Detail: HDS's documented policies and procedures are referenced throughout this matrix as the administrative backing for the technical controls, and they are reviewed periodically. The platform enforces the decisions those policies make but does not author them. A partner attesting under SOC 2 keeps its own policy and procedure set; it cannot inherit HDS's, though it can cite HDS's programme where HDS operates the underlying system. Evidence: internal:hipaa/policies/information-security-policy, internal:soc2/procedures/control-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Author and maintain your own policies and operating procedures that deploy your selected control activities. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Maintain your own policies and procedures for the service you run downstream. ## soc2 CC6.1 — CC6.1 — Logical access security over protected information assets Requirement: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-1 PRYV PLATFORM: implemented Logical access is enforced by Pryv at the API surface: every read/write is checked against the access's per-stream + level permissions, token-based authentication is the default, and MFA is available via the mfa.* methods when you enable it. System streams isolate privileged data (credentials, MFA state). No plaintext transport path ships. You define who gets which access; Pryv enforces it. Detail: **OAuth2 as a second logical-access path.** Alongside token + MFA authentication, Pryv ships a standards-based OAuth2 authorization-code + PKCE authorization server (`open-pryv.io/components/oauth2/`, open-pryv.io 2.0.0-rc.8): discovery at `GET /.well-known/oauth-authorization-server`, `GET /oauth2/authorize`, and `POST /oauth2/token`. PKCE is mandatory (S256 only); presented redirect URIs are validated by exact string match with a single loopback-port carve-out (RFC 8252 / 9700) and fragment-bearing redirect URIs are rejected (`open-pryv.io/components/oauth2/src/clientRegistry.ts`). Client registration is curated-only, the operator promotes an account to an OAuth client via `bin/oauth-client.js`; open self-service registration (`POST /oauth2/register`) is deliberately disabled. **Credential transmission to third parties.** When a credential must be handed to a counterparty, the shared-secrets endpoints (`open-pryv.io/components/shared-secrets/`) replace URL-embedded tokens with a one-time random key: redeemable exactly once (with atomic single-winner semantics under concurrent redemption), mandatory TTL, only the SHA-256 of the key's random half stored server-side, payload scrubbed when the item leaves the pending state (on redemption, on a signature mismatch, and on the first retrieval attempt after the TTL; expiry is enforced on access, not by a background sweeper, so an untouched expired secret keeps its payload until something reaches it or you delete it), optional passphrase / HMAC signature on redemption. Browser history, referrer headers, and access logs therefore stop carrying live credentials. A `secretSharing: forbidden` feature permission, inherited by child accesses and not strippable via `accesses.update`, lets you exclude designated access classes from minting shared secrets at all. PLANNED (enhancement, impact medium): Reference TOTP / WebAuthn MFA plugins + AAL-tier mapping strengthen the CC6.1 authentication-strength evidence HDS: implemented (effort saved: high) Logical access is enforced by the HDS-operated platform at the API surface: every read or write is checked against the access's per-stream and per-level permissions, token-based authentication is the default, multi-factor authentication is available, and privileged data is held on a separately controlled namespace. No plaintext transport path is served. An organization defines who gets which access; HDS operates the enforcement. Detail: Logical access security is a technical property of the API boundary, not a downstream policy layer. Each request must present a valid access token whose per-stream, per-level permissions are checked before any data is touched; credentials and privileged state live on a separately controlled namespace; MFA strengthens the login where configured. HDS operates this stack across every data-residency option and documents its access-control and authentication policy. The implementer configures which grants its application mints. Evidence: internal:hipaa/policies/access-control, internal:hipaa/policies/authentication Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [stores-phi-copy, connects] Configure least-privilege per-stream access grants for your application and document your access-authorization rules; decide whether to require MFA. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy, connects]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [stores-phi-copy, connects] Apply the same logical-access controls to the service you run downstream. ## soc2 CC6.2 — CC6.2 — Registration, credential issuance, and de-provisioning Requirement: Before issuing credentials and granting access, the entity registers and authorizes new users; credentials are removed when access is no longer authorized. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-2 PRYV PLATFORM: implemented The full credential lifecycle is Pryv primitives: registration mints an account; accesses.create issues a scoped credential; accesses.update modifies scope (writing the prior version to history); accesses.delete revokes; system.users.delete removes the account entirely. Each stage lands in the audit log. The authorization decision (who may register, what scope is appropriate) is your policy; the mechanism is shipped. Detail: **OAuth2 client credential issuance is curated.** For delegated-app credentials, Pryv issues OAuth2 client identities only through the operator CLI (`bin/oauth-client.js`, register / rotate-secret / list), not through open dynamic registration: the discovery document advertises no registration endpoint and `POST /oauth2/register` (RFC 7591 open mode) is intentionally deferred, `oauth.clientRegistration.mode: curated` is the only supported value and `open` is rejected. Each client carries an exact-match set of registered redirect URIs and, for confidential clients, a rotatable `client_secret`. The authorization decision (who becomes a client, which redirect URIs + scopes are appropriate) stays your policy; the issuance + rotation mechanism is shipped (`open-pryv.io/components/oauth2/`, open-pryv.io 2.0.0-rc.8). HDS: implemented (effort saved: high) The full credential lifecycle is platform-native and HDS-operated: registration mints an account, a scoped access token issues a credential, updating an access modifies its scope (writing the prior version to history), and revocation or account deletion removes it. Each stage lands in the audit log. The authorization decision (who may register, what scope is appropriate) is an organization's policy; the mechanism is shipped. Detail: Registration, issuance, modification and de-provisioning are all first-class operations: an access token is the credential, its scope is adjustable with full version history, and revocation takes effect immediately. Account deletion removes the identity entirely. Every step is audited. HDS operates this lifecycle and documents the access-authorization and termination procedures it follows for its own workforce; the implementer applies the same primitives to its users. Evidence: internal:hipaa/policies/access-authorization, internal:hipaa/procedures/access-termination Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [connects] Document who may register and authorize users and at what scope, and tie de-provisioning to immediate access revocation. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [connects]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [connects] Operate the same registration and de-provisioning lifecycle downstream. ## soc2 CC6.3 — CC6.3 — Role-based access, least privilege, and segregation of duties Requirement: The entity authorizes, modifies, and removes access based on roles and the system design, applying least privilege and segregation of duties. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-3 PRYV PLATFORM: implemented Least privilege is native: an access carries only the stream+level tuples it needs (none / create-only / read / contribute / manage), so a credential cannot touch out-of-scope data. Segregation of duties is expressed by issuing distinct narrow accesses per role, with system streams isolating privileged functions. accesses.update / .delete cover modify + remove; access version history is the review-evidence layer. Role definitions live in your IdP / policy; Pryv records and enforces the resulting access state. Detail: For workforce / role-scale deployments, Pryv composes with an external IdP / IGA system rather than implementing roles + groups itself, two integration patterns (group access + callerId audit suffix; seed access + sub-access derivation) are documented in context/workforce-access-patterns.md. The IdP stays the source of truth for identity; Pryv records the access state + per-individual audit trail. **OAuth2 revoke + refresh-chain teardown.** For delegated apps, the durable consent behind an OAuth2 grant is a cross-account CMC data-grant; revoking it (deleting the counterparty access) kills the refresh chain, the next `refresh_token` exchange sees the data-grant gone and fails `invalid_grant`, so no fresh access is minted (`open-pryv.io/components/oauth2/src/grants/refresh_token.ts`, open-pryv.io 2.0.0-rc.8). Access modification propagates the same way: narrowing the granted permissions on the data-grant narrows what the next rotated token can do; widening requires a fresh consent, never a refresh. **Operator client revocation reaches live tokens.** Revoking a delegated app (`bin/oauth-client.js revoke `) no longer merely blocks new grants while issued tokens live out their TTL: it writes a platform-wide tombstone and every core rejects that client's existing access tokens at validation time within `oauth.clientRevokeCheckSeconds` (default 30 s), open socket.io connections are swept and dropped too. So "remove access for app X, everywhere, now" is one operator command with a bounded propagation window (open-pryv.io `7b6321aa`). For DPoP-bound apps the same is available per client key (`revoke-key `, open-pryv.io `4c0a5ade`). HDS: implemented (effort saved: high) Least privilege is native to the HDS-operated platform: an access carries only the per-stream, per-level permissions it needs, so a credential cannot touch out-of-scope data. Segregation of duties is expressed by issuing distinct narrow accesses per role, with privileged functions isolated on a separate namespace. Modification and removal are audited operations with version history as the review-evidence layer. Detail: The permission model makes least privilege the default rather than an aim: each access lists exactly the streams and levels it may exercise. Distinct roles map to distinct narrow accesses, giving segregation of duties; privileged namespaces isolate sensitive functions. Access updates and revocations are audited and version-history-tracked. Role definitions live in an organization's identity system or policy; HDS records and enforces the resulting access state and documents its own access-review cadence. Evidence: internal:hipaa/policies/access-control, internal:hipaa/procedures/access-review Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [connects] Define your role model and least-privilege scopes, map them onto access grants, and run a periodic access review over the version history. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [connects]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [connects] Apply role-based least-privilege access and segregation of duties downstream. ## soc2 CC6.4 — CC6.4 — Physical access to facilities and protected assets Requirement: The entity restricts physical access to facilities and protected information assets to authorized personnel. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-4 PRYV PLATFORM: out-of-scope Physical access control (data-center entry, badge systems, media vaults) is facility scope, outside Pryv's software boundary. Your hosting provider carries this, an HDS- or ISO 27001-certified hoster typically inherits it from the underlying CSP and provides the attestation you reference. HDS: facilitated (effort saved: medium) (mode: infrastructure) Physical access control (data-centre entry, media handling) is facility scope, outside the platform software boundary. HDS carries this layer by selecting certified hosting providers for each region (EU/Switzerland and US data-residency options) and holding their facility-control attestations on file, so an organization inherits a vetted physical posture for the server tier rather than sourcing it itself. Detail: HDS does not operate its own data centres; it deploys the platform onto certified infrastructure whose physical access controls are independently attested, and records which attestation backs each region in its hosting-provider register. The server-tier physical-access obligation is satisfied by inheritance; an organization's own facilities (offices where workforce access the service) remain its responsibility. Evidence: internal:hipaa/registers/hosting-provider-attestations Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Inherit the server-tier facility controls from the HDS hosting region and reference the attestation; control and document physical access to your own premises. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Document the physical controls for any facilities you operate downstream. ## soc2 CC6.5 — CC6.5 — Protections over data and software on disposed assets Requirement: The entity removes logical and physical protections over physical assets only after the ability to read or recover the data and software from them has been diminished and is no longer required. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-5 PRYV PLATFORM: configurable Logical destruction is per-user: system.users.delete removes the user's data from the live store; event- and stream-level deletion cover per-record needs. Whether destruction extends to backups is engine-dependent, SQLite stores one file per user (unlink = gone), PostgreSQL deletes rows but historical pg_dump artefacts retain them until rotated. Choose the engine that matches your destruction policy; physical media sanitisation is your hosting procedure. HDS: configurable (effort saved: medium) Logical destruction is per-user on the HDS-operated platform: account deletion removes a user's data from the live store, and event- and stream-level deletion cover per-record needs. Whether destruction extends to backups is storage-engine-dependent, so the engine is chosen to match the destruction policy. Physical media sanitisation at the server tier is the certified hosting provider's procedure. Detail: Per-user erasure gives a clean logical-destruction path; backup reach depends on the configured storage engine (a per-user file model unlinks cleanly, a shared relational store retains rows in historical dump artefacts until rotated). HDS documents the engine posture it operates and relies on the hosting provider's media-sanitisation for physical disposal, which is evidenced by third-party attestation for the US region while the Swiss region rests on contract alone, with nothing yet on file. An organization selects the engine matching its disposal commitment. Evidence: internal:hipaa/registers/hosting-provider-attestations Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: configurable applies_when: [stores-phi-copy] Choose the storage engine that matches your destruction policy and document how backup-resident copies are aged out. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: configurable applies_when: [stores-phi-copy] Make the same engine and sanitisation choices for the service you run downstream. ## soc2 CC6.6 — CC6.6 — Boundary protection against external threats Requirement: The entity implements logical access security measures to protect against threats originating outside its system boundaries. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-6 PRYV PLATFORM: implemented The external boundary is the TLS-terminating HTTPS API: TLS 1.3 in transit with the built-in ACME integration (auto-renewal + cluster-replicated rotation), token-gated access on every request, no plaintext path. Inter-core traffic in a cluster runs over mTLS on a private CA, separating the control plane from the user-facing plane. Edge controls (WAF, firewall, rate limiting) sit in your reverse proxy by design, see context/rate-limiting-and-dos-protection.md. HDS: implemented (effort saved: high) The external boundary is the TLS-terminating HTTPS API HDS operates: TLS in transit with automated certificate renewal, token-gated access on every request, and no plaintext path. Inter-core traffic in a cluster runs over mutually authenticated transport, separating the control plane from the user-facing plane. Edge controls (WAF, firewall, rate limiting) sit in the operator's reverse proxy by design. Detail: Boundary protection is enforced technically: every request crosses a TLS boundary and presents a valid access token before reaching data, and cluster-internal transport is mutually authenticated on a private CA. HDS operates the certificate lifecycle and the edge controls (rate limiting, firewalling) at the reverse proxy in each region. An organization inherits this boundary and configures any additional edge policy its risk analysis requires. Evidence: internal:hipaa/policies/transmission-security, internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Inherit the TLS and token boundary; configure and document any additional edge controls (WAF, rate limits) your risk analysis calls for. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate equivalent boundary protection for the service you run downstream. ## soc2 CC6.7 — CC6.7 — Restriction and protection of information in transmission and movement Requirement: The entity restricts the transmission, movement, and removal of information to authorized users and processes, and protects it during transmission, movement, or removal. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-7 PRYV PLATFORM: implemented Transmission is TLS 1.3 end-to-end (client ↔ core direct, no Pryv-shipped intermediary that could log or cache). Movement is restricted by the permission model, a credential only moves the data its scope permits. Operator secrets at rest use AES-256-GCM (HKDF-derived per-key); bootstrap bundles for core-to-core movement are AES-256-GCM (scrypt). Bulk event-data at-rest encryption is an operator-side storage-layer choice (LUKS / SSE-KMS / customer keys). HDS: implemented (effort saved: high) Transmission is protected by TLS end to end (client to core direct, with no HDS-shipped intermediary that could log or cache), and movement is restricted by the permission model — a credential only moves the data its scope permits. Operator secrets at rest and bootstrap bundles for core-to-core movement are encrypted with authenticated encryption. Bulk event data is encrypted at rest at the hosting/storage layer in every region (since 2026-06-26), with provider-managed keys as the documented residual. Detail: The transmission half is default-on TLS with no plaintext path; the movement half is bounded by the access permission model, so data only moves where a scope permits and there is no out-of-band dump path. Operator secrets and core-to-core bootstrap material use authenticated encryption at rest. Event data at rest is protected by hosting-layer full-volume encryption in each region; keys are provider-managed, so platform-managed content encryption (operator-held-key volumes or end-to-end) remains an optional strengthening an organization weighs in its risk analysis. Evidence: internal:hipaa/policies/transmission-security, internal:hipaa/policies/encryption, internal:hipaa/risk/at-rest-encryption, internal:hipaa/evidence/at-rest-encryption-verification Evidence backing: every internal document cited above has completed approval. PLANNED (platform, impact medium): End-to-end / operator-held-key encryption is queued upstream as the strengthening for the provider-managed-key at-rest residual; claimable here only after pryv ships it AND HDS deploys and enables it on all cores. IMPLEMENTER [service-organization] coverage: configurable applies_when: [stores-phi-copy] Rely on default-on TLS and the permission-bounded movement model; weigh the provider-managed-key at-rest residual in your risk analysis and add application-side encryption where your assessment requires it. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: configurable applies_when: [stores-phi-copy] Make the same transmission and at-rest choices for the service you run downstream. ## soc2 CC6.8 — CC6.8 — Prevention and detection of unauthorized or malicious software Requirement: The entity implements controls to prevent, or detect and act upon, the introduction of unauthorized or malicious software. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc6-8 PRYV PLATFORM: facilitated (mode: evidence) Anti-malware / endpoint protection is a host-and-network control, not shipped in Pryv. Pryv's contribution is detection-adjacent: server-side event-type validation rejects malformed payloads at ingest, the dependency-audit pipeline guards the software supply chain, and audit + observability surface anomalous behaviour. AV + application-allowlisting on the hosts is your operator scope. HDS: facilitated (effort saved: low) (mode: infrastructure) Anti-malware and endpoint protection are host-and-network controls, not platform features. HDS operates malware protection and patching at the hosting layer for the environments it runs, documented internally. The platform contributes detection-adjacent properties: server-side payload validation rejects malformed input at ingest, and the audit and monitoring substrate surfaces anomalous behaviour. Detail: HDS carries malware protection as operator-side infrastructure hardening for the environments it runs; the platform software itself ships no antivirus. Its indirect contribution is structural input validation at ingest and the anomaly signal from audit and monitoring. An organization protects its own endpoints and any infrastructure it operates outside HDS, and operates application-allowlisting on its hosts. Evidence: internal:hipaa/policies/malware-protection Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Operate and document anti-malware and application-allowlisting on your own endpoints and any infrastructure you run outside HDS. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate equivalent malware controls for the infrastructure you run downstream. ## soc2 CC7.1 — CC7.1 — Detection of configuration changes and vulnerabilities Requirement: The entity uses detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibility to newly discovered vulnerabilities. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc7-1 PRYV PLATFORM: facilitated (mode: evidence) Pryv-side substrate-vulnerability detection now has an active, CI-enforced feed (open-pryv.io master merge `9e2ee7ff`): a runtime-dependency audit gate fails every build on high or critical advisories in the shipped npm tree (accepted advisories live in a documented allowlist, not silenced), a CycloneDX SBOM is emitted and Grype-scanned on every CI run (build fails on critical findings), the base image is digest-pinned with the rqlite download checksum-verified, and release images are cosign-signed with a SLSA build-provenance attestation. Dependabot alerts, CHANGELOG announcements, and a config-validation step that fails fast on malformed configuration at master start round this out; observability + audit surface runtime anomalies. Base-image OS-level CVEs remain visible to the scanners (a slimmer-base migration is a tracked follow-up). Your own scanning cadence for the layers you add sits on top. HDS: facilitated (effort saved: low) (mode: evidence) Substrate-vulnerability detection on the platform side is partial: a committed dependency lockfile, dependency alerts on the open-source codebase, published fix announcements, and a config-validation step that fails fast on malformed configuration at start. Operational monitoring and the audit log surface runtime anomalies. HDS operates this and layers its own patching cadence; an organization's own vulnerability-scanning cadence sits on top. Detail: The platform contributes passive detection (lockfile, dependency alerts, fail-fast config validation) plus the runtime anomaly signal from monitoring and audit. HDS operates a patching and update process over the platform and documents it. A partner defines its own vulnerability-scanning and configuration-drift detection cadence over the same substrate. Evidence: internal:hipaa/policies/audit-controls, internal:soc2/procedures/control-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define your own vulnerability-scanning and configuration-drift detection cadence over the platform and your own infrastructure. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate equivalent vulnerability detection for the service you run downstream. ## soc2 CC7.2 — CC7.2 — Monitoring for anomalies indicative of security events Requirement: The entity monitors system components for anomalies indicative of malicious acts, natural disasters, and errors, and analyzes them to determine whether they represent security events. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc7-2 PRYV PLATFORM: facilitated (mode: evidence) The pluggable observability provider gives system-level anomaly signal (latency, error rate, request volume); the per-user audit log gives application-level activity, attributable to an access. Anomaly-detection logic on the audit stream itself is a natural extension you build; the raw signal is shipped. HDS: facilitated (effort saved: medium) (mode: evidence) HDS's operational monitoring gives system-level anomaly signal (latency, error rate, request volume) across every data-residency option, wired end to end with alerting before any component is treated as in production; the per-user audit log gives application-level activity attributable to an access. HDS operates this monitoring; deciding which anomalies are security events is an organization's analysis. Detail: Two signal sources back anomaly monitoring: HDS's infrastructure monitoring and the audit log. HDS treats end-to-end alert wiring as a precondition for treating any component as in production, so an outright silent failure is caught. Security-relevant anomaly detection is less complete: automated login-anomaly detection and alert thresholds are not formalised, and what operates today is manual review of forwarded logs on a quarterly cadence. The analytical step, classifying an anomaly as a security event, is governance and is each organization's own, fed by the raw signal HDS exposes and operates. Evidence: internal:hipaa/policies/audit-controls, internal:hipaa/procedures/login-monitoring Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define your anomaly thresholds and the analysis that classifies an anomaly as a security event, drawing on the monitoring and audit substrate. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate equivalent anomaly monitoring for the service you run downstream. ## soc2 CC7.3 — CC7.3 — Evaluation of security events Requirement: The entity evaluates security events to determine whether they could result, or have resulted, in a failure to meet its objectives, and takes action. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc7-3 PRYV PLATFORM: facilitated (mode: evidence) Event-vs-incident classification is your decision. Pryv supplies the evaluation inputs, audit row patterns, observability anomalies, but the categorisation rule and the response trigger are your policy. HDS: facilitated (effort saved: low) (mode: evidence) Event-versus-incident classification is each organization's decision. The platform and HDS monitoring supply the evaluation inputs — audit-row patterns and monitoring anomalies — but the categorisation rule and the response trigger are policy. HDS operates its own event-evaluation step as part of its incident-response procedure and documents it. Detail: HDS evaluates the security events it observes in its own operation using audit and monitoring inputs, against the criteria in its incident-response procedure. A partner authors its own classification rule and response triggers over the same inputs. The substrate is operated; the judgement is governance. Evidence: internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define how you classify a security event as an incident and what response it triggers. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate your own event-evaluation step for the service you run downstream. ## soc2 CC7.4 — CC7.4 — Incident response program Requirement: The entity responds to identified security incidents through a defined program to understand, contain, remediate, and communicate them. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc7-4 PRYV PLATFORM: facilitated (mode: evidence) Pryv contributes the technical halves of incident response: detection + scoping (audit + observability) and containment (accesses.delete revokes a compromised credential immediately). The external intake channel for substrate-vulnerability reports is published in `SECURITY.md` (coordinated disclosure policy: private GHSA flow + `security-dev@` mailbox + SLA + scope + safe harbor; private vulnerability reporting enabled on the published repositories). The incident-response program itself, roles, escalation, communications, lessons-learned, is yours to define and rehearse. PLANNED (feature, impact low): Chained / signed audit log strengthens forensic evidence during incident analysis (F:Evidence Med → High) HDS: facilitated (effort saved: medium) (mode: evidence) The platform contributes the technical halves of incident response: detection and scoping (audit log plus monitoring) and containment (immediate revocation of a compromised access). HDS runs its own incident-response programme as operator — roles, escalation, communications — and documents it; that programme feeds the notification obligations a partner carries. The partner defines and rehearses its own programme. Detail: HDS operates an incident-response procedure: detection draws on audit and monitoring, containment uses immediate access revocation or scope reduction, and a documented flow governs escalation and communication. The procedure is held internally and shared on request, and feeds breach-notification timing a partner must honour. For substrate vulnerabilities, the upstream open-pryv.io project's coordinated vulnerability disclosure program (private GitHub Security Advisories plus a security mailbox, GHSA/CVE issuance) is the external intake channel; a published advisory affecting the deployed release enters HDS's procedure as a provider notification. A partner authors and rehearses its own incident-response programme over the same technical substrate. Evidence: internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define and rehearse your own incident-response programme — roles, escalation, containment, communication, lessons learned — over the platform detection and containment primitives. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Run your own incident-response programme and notify your upstream service organization of incidents affecting their data. ## soc2 CC7.5 — CC7.5 — Recovery from identified security incidents Requirement: The entity identifies, develops, and implements activities to recover from identified security incidents. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc7-5 PRYV PLATFORM: facilitated (mode: infrastructure) Recovery primitives: bin/backup.js + --restore rebuild a user from backup; a multi-core cluster gives in-line Raft replication + cluster-replicated TLS certs so a surviving core keeps serving when a peer fails. The recovery-objective targets (RTO / RPO) and the drill cadence are your policy. HDS: facilitated (effort saved: medium) (mode: infrastructure) Recovery primitives ship and HDS operates them: per-user backup and restore rebuild a subject from backup, and a replicated multi-core topology with cluster-replicated certificates keeps a surviving core serving when a peer fails. HDS documents the recovery objectives and runbook it operates; the recovery-objective targets and drill cadence for an organization's own service are its own. Detail: Recovery rests on two layers HDS operates: cold restore from per-user backups as the canonical path, and live replication across cores so a single-region failure does not lose live data. HDS documents the recovery objectives it targets; verified, regularly tested recovery drilling is being matured (see CC4.1 evaluation). A partner sets its own recovery-objective targets and drill cadence over the same primitives. Evidence: internal:hipaa/procedures/disaster-recovery-plan, internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Set your recovery-objective targets and drill cadence, and document the recovery runbook over the platform backup and replication primitives. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate your own recovery activities for the service you run downstream. ## soc2 CC8.1 — CC8.1 — Authorized changes to infrastructure, data, software, and procedures Requirement: The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc8-1 PRYV PLATFORM: facilitated (mode: evidence) Pryv-side change evidence: tagged releases, SHA-pinned Docker images, CHANGELOG-v2 + CHANGELOG-v2-back per release, an engine-agnostic forward-only schema-migration framework (bin/migrate.js, with autoRunOnStart), and a public CI test matrix (PostgreSQL + SQLite). Separate dev / test / prod environments are supported via independent core deployments. The audit log records config-driven behaviour changes in your deployment. Your change-approval workflow (windows, sign-off, rollback) sits on top. HDS: documented (effort saved: low) Platform-side change evidence is strong: tagged releases, SHA-pinned images, per-release change notes, a forward-only schema-migration framework, and a public CI test matrix; separate environments are supported via independent deployments, and the audit log records config-driven behaviour change. HDS is honest, though, that its own formalised change-management programme (windows, sign-off, rollback) is still being matured — a known gap. Detail: The substrate supplies the raw change artefacts an auditor samples. What is not yet fully formalised is HDS's own change-approval workflow as a documented, verified programme — HDS states this gap plainly rather than claiming an implemented change-management control. HDS documents its current change handling and is maturing it. A partner authors its own change-management programme over the platform's change-evidence substrate. Evidence: internal:hipaa/policies/audit-controls, internal:soc2/policies/change-management PLANNED (doc, impact medium): A written change-management process (ticketed approvals, documented test evidence per change, rollback) is drafted in the internal pipeline; its formalisation is the tracked remediation. IMPLEMENTER [service-organization] coverage: documented applies_when: always Author and document your own change-management workflow — authorization, testing, approval, rollback — using the platform change-evidence artefacts. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate your own change-management programme for the service you run downstream. ## soc2 CC9.1 — CC9.1 — Risk mitigation for business disruptions Requirement: The entity identifies, selects, and develops risk-mitigation activities for risks arising from potential business disruptions. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc9-1 PRYV PLATFORM: facilitated (mode: infrastructure) Disruption-mitigation inheritance: multi-core HA + Raft replication, backup-restore, cluster-replicated TLS certificates, and a clean cloud-exit path (re-issue the cluster onto new infrastructure from a bootstrap bundle). The business-continuity objectives and the insurance / contractual mitigation choices are yours. HDS: facilitated (effort saved: medium) (mode: infrastructure) Disruption-mitigation primitives are inherited and HDS-operated: multi-core high availability with replication, per-user backup and restore, cluster-replicated certificates, and a clean cloud-exit path (re-issue the cluster onto new infrastructure from a bootstrap bundle). HDS documents the continuity posture it operates; the business-continuity objectives and any insurance or contractual mitigation choices are an organization's own. Detail: HDS operates the technical continuity substrate: HA replication, backup and restore, replicated TLS certificates and portable cluster re-issue, across both data-residency options, and documents it. What has not happened is the per-region production drill, so the continuity objectives are targets rather than demonstrated capability. The non-technical mitigation choices (continuity objectives, insurance, contractual risk transfer) are governance and belong to each attesting organization. HDS's security risk analysis is approved and would prioritise these mitigations; what it does not cover is the wider trust-services and fraud half, which is the outstanding piece under CC3.2. Evidence: internal:hipaa/procedures/disaster-recovery-plan, internal:hipaa/procedures/data-backup-plan Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Set your business-continuity objectives and choose your non-technical mitigations over the platform HA and backup substrate HDS operates. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always Operate equivalent disruption mitigation for the service you run downstream. ## soc2 CC9.2 — CC9.2 — Vendor and business-partner risk management Requirement: The entity assesses and manages risks associated with its vendors and business partners. Anchor: https://compliance.datasafe.dev/soc2.html#req-cc9-2 PRYV PLATFORM: facilitated (mode: awareness) Where Pryv is your vendor (open-pryv.io as a third-party, BSD-licensed platform), the public release process + CHANGELOGs + this compliance matrix are the vendor-monitoring artefact set you reference. Your broader vendor-risk programme (assessment criteria, SLA reviews, subprocessor inventory) sits on top. Detail: Supply-chain risk on the Pryv substrate is actively managed upstream: committed lockfile + Dependabot, a CI runtime-dependency audit gate, CycloneDX SBOM emission with Grype scanning, a digest-pinned base image, and cosign-signed release images with SLSA provenance (open-pryv.io merge `9e2ee7ff`). The SBOM + signature + CHANGELOG set is the vendor-monitoring artefact you cite when Pryv is the vendor under review. See CC7.1. HDS: documented (effort saved: low) Where the platform is an organization's vendor, the public release process, change notes and this compliance matrix are the vendor-monitoring artefact set it references. HDS maintains a subprocessor register for its own downstream vendors. HDS is honest that a formalised vendor-management programme (assessment criteria, SLA reviews) is still being matured — a known gap. Detail: HDS's contribution has two parts. As a vendor it exposes a transparent release process and this matrix for monitoring. As an operator it holds a subprocessor register listing its own downstream vendors, available to partners for their due diligence. HDS states plainly that its full vendor-risk programme — assessment criteria, periodic reassessment, SLA review — is not yet formalised. A partner runs its own vendor-risk programme, treating HDS as one assessed vendor. Evidence: internal:hipaa/registers/subprocessor-register, internal:soc2/policies/vendor-management PLANNED (doc, impact medium): A formal vendor-management programme (assessment criteria, scored risk tiers, scheduled re-assessment and SLA review) is drafted in the internal pipeline; its formalisation is the tracked remediation. IMPLEMENTER [service-organization] coverage: documented applies_when: [third-parties] Run your own vendor-risk programme; assess HDS as a vendor using its release process, this matrix and its subprocessor register. Templates to sign: subprocessor IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [third-parties]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [third-parties] Manage the risk of your own downstream vendors and flow obligations through to them. Templates to sign: subcontractor ## soc2 A1.1 — A1.1 — Capacity management Requirement: The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable additional capacity in support of its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-a1-1 PRYV PLATFORM: facilitated (mode: infrastructure) Capacity signal comes from per-core observability metrics (memory, CPU, latency, request volume); capacity grows by adding cores to the cluster (each serves its bound users behind the shared rqlite control plane). The capacity-planning cadence and provisioning automation are yours. HDS: facilitated (effort saved: medium) (mode: infrastructure) HDS runs the platform on a topology that scales horizontally (cores added to a cluster), and operates infrastructure-level monitoring of memory, CPU, latency and request volume across both the US and Switzerland data-residency options. The capacity-planning cadence, its thresholds and provisioning triggers, is an operator procedure HDS documents and has not yet exercised; the user-entity inherits the headroom rather than sizing it. Detail: Capacity signal comes from the platform's observability metrics plus HDS's own infrastructure telemetry, and capacity is added by extending the cluster. The written capacity-management procedure HDS operates is held internally and shared on request; it defines a monthly review cadence, and the first such review has not yet been run, so the cadence is defined rather than evidenced by a dated note. A user-entity running its own deployment performs its own capacity planning. Evidence: internal:soc2/procedures/capacity-management Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [stores-phi-copy] Define and document your own capacity-planning thresholds and the provisioning workflow if you operate your own deployment; otherwise rely on the HDS-operated capacity posture and reference it. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [stores-phi-copy] Where a hosting subservice carries the underlying compute, its capacity commitments back this control; record the reliance. ## soc2 A1.2 — A1.2 — Environmental protections, backup, and recovery infrastructure Requirement: The entity authorizes, designs, implements, operates, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-a1-2 PRYV PLATFORM: facilitated (mode: infrastructure) Backup + recovery infrastructure ships: bin/backup.js produces per-user backups, multi-core topology gives in-line Raft replication, TLS certs replicate across the cluster so a surviving core stays user-facing. Environmental protections (power, cooling, fire suppression) are facility-side; your hoster's certification covers them. Backup cadence, retention, and offsite policy are yours. HDS: facilitated (effort saved: high) (mode: infrastructure) The platform ships per-user backup and restore and a replicated multi-core topology, and HDS operates these with cluster-replicated TLS so a surviving core stays user-facing. Environmental protections (power, cooling, fire suppression) are inherited from the certified hosting provider per region. Backups run automatically on a daily timer and were verified live on all cores on 2026-07-30; what remains unproven is recovery at production scale per region, so this is facilitated rather than fully implemented. Detail: HDS runs the backup primitive on a daily timer per regional core, relies on multi-core replication for hot redundancy, and documents the recovery infrastructure it operates. A host-side watchdog alerts when an expected archive is absent, though its own configuration rests on attestation rather than a captured record and it has not yet fired for real. Environmental controls at the facility tier are covered by the hosting provider's attestation, which HDS records. The outstanding item is the per-region production recovery drill. A user-entity running its own deployment defines its own schedule. Evidence: internal:hipaa/procedures/data-backup-plan, internal:hipaa/procedures/disaster-recovery-plan Evidence backing: every internal document cited above has completed approval. PLANNED (procedure, impact medium): The scheduled backup cycle is running on both regional cores as of 2026-07-30, producing encrypted off-host in-region copies, and an archive has been retrieved and decrypted with the off-host key to show the copies are usable. The tracked remainder is the per-region production restore drill at non-trivial scale and confirmation of the storage lifecycle backstop. IMPLEMENTER [service-organization] coverage: documented applies_when: [stores-phi-copy] Document your backup schedule, retention and offsite policy, and confirm restorability; if you operate your own deployment, run the backup and replication primitives yourself. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [stores-phi-copy] The hosting subservice carries environmental protections at the facility tier; obtain and retain its attestation. ## soc2 A1.3 — A1.3 — Recovery plan testing Requirement: The entity tests recovery plan procedures supporting system recovery to meet its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-a1-3 PRYV PLATFORM: facilitated (mode: evidence) Pryv gives you a testable recovery path (restore a user from a backup file into a clean core; fail a core and confirm a peer keeps serving). The recovery drill, scheduling it, evidencing the result, feeding gaps back into the plan, is your operating procedure. HDS: facilitated (effort saved: low) (mode: evidence) The platform provides a testable recovery path (restore a user from a backup into a clean core; fail a core and confirm a peer keeps serving), and HDS documents the intended recovery-test cadence. Regular, verified execution of the drill is a known gap being matured, so HDS facilitates this rather than evidencing a fully operated test programme. Detail: Restore and failover are exercisable against the platform primitives. HDS documents the recovery-test procedure it intends to run and feeds gaps back into the plan; scheduled, verified drills with retained evidence are being formalised and are stated plainly as a gap. A user-entity runs and evidences its own recovery tests for its workload. Evidence: internal:hipaa/procedures/contingency-plan-testing Evidence backing: every internal document cited above has completed approval. PLANNED (procedure, impact medium): The contingency-test procedure is approved and a first restore rehearsal was performed on 2026-07-29 with a retained execution record. It covered a single account, not a full per-region restore, so recovery at production scale is the tracked remainder. IMPLEMENTER [service-organization] coverage: documented applies_when: [stores-phi-copy] Schedule, run and document recovery-plan tests for the parts of the system you operate, and revise the plan from the results. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA ## soc2 C1.1 — C1.1 — Identification and maintenance of confidential information Requirement: The entity identifies and maintains confidential information to meet its objectives related to confidentiality. Anchor: https://compliance.datasafe.dev/soc2.html#req-c1-1 PRYV PLATFORM: facilitated (mode: primitive) Pryv lets you identify + isolate confidential data by stream layout: dedicate subtrees per confidentiality tier and gate each with a distinct permission scope, so confidential streams are reachable only by credentials granted them. System streams add a privileged tier independent of your scheme; clientData / event type can carry machine-readable classification labels. Masking is by projection (stream + permissions), not value transformation, see context/data-masking-projection-vs-transformation.md. PLANNED (feature, impact low): End-to-end (proxy re-encryption / BYOK) keeps confidential content opaque to the operator; the natural future confidentiality primitive HDS: implemented (effort saved: high) Confidential data is identified and isolated structurally on the HDS-operated platform: subject data is per-user isolated, and confidential streams are reachable only by access tokens granted the matching per-stream permission, with privileged namespaces (credentials) separately controlled. Where the account identity is itself confidential, the platform's alias primitive (`accesses.create {randomAlias:true}`, deployed on the HDS cores since 2026-07-28) lets a grant expose a random routable alias in place of the username. HDS operates this access-controlled isolation and documents its confidentiality and access-control posture. Detail: Identification and maintenance of confidential information is enforced by stream layout plus the permission model rather than left to downstream policy: a credential can reach only the confidential streams it was granted, at the level granted, on every API call. HDS operates this stack and documents the access-control and minimum-necessary policies behind it. The user-entity decides which streams carry which confidentiality tier and which grants its application mints. Evidence: internal:hipaa/policies/access-control, internal:hipaa/policies/minimum-necessary Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [stores-phi-copy, analytics] Classify your confidential data, map it to a stream layout, and grant least-privilege per-stream access; document the classification scheme. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy, analytics]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: [stores-phi-copy, analytics]; PLACES NO DUTY ON THIS PERSONA ## soc2 C1.2 — C1.2 — Disposal of confidential information Requirement: The entity disposes of confidential information to meet its objectives related to confidentiality. Anchor: https://compliance.datasafe.dev/soc2.html#req-c1-2 PRYV PLATFORM: configurable Confidential-data disposal uses the same per-user erasure path as CC6.5: system.users.delete for whole-account, event/stream deletion for per-record. Backup reach is engine-dependent (SQLite per-user file vs PostgreSQL row + pg_dump rotation), pick the engine that matches your disposal commitment. HDS: facilitated (effort saved: medium) (mode: storage) The platform provides per-user erasure (whole-account deletion, plus event- and stream-level deletion) from the live store, which HDS operates. Whether disposal reaches backups is storage-engine-dependent, and formal, scheduled data-disposal automation is not yet shipped — so HDS facilitates this and documents the boundary rather than claiming full disposal. Detail: Logical destruction in the live store is concrete: account deletion removes a user's data, and event/stream deletion covers per-record needs. Backup reach depends on the configured engine, and a documented retention-and- disposal schedule with verified backup pruning is a known gap being matured. HDS documents the disposal path and its limits; the user-entity chooses the engine that matches its disposal commitment and applies media sanitisation at the hosting tier. Evidence: internal:hipaa/policies/minimum-necessary, internal:soc2/procedures/data-retention-and-disposal PLANNED (doc, impact low): A documented retention-and-disposal schedule with verified backup pruning is drafted in the internal pipeline; its formalisation is the tracked remediation. IMPLEMENTER [service-organization] coverage: documented applies_when: [stores-phi-copy] Define your disposal schedule and triggers, choose a storage engine whose backup behaviour matches it, and document the procedure. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [stores-phi-copy]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [stores-phi-copy] The hosting subservice carries physical media sanitisation; obtain and record its attestation. ## soc2 PI1.1 — PI1.1 — Quality information about processing objectives Requirement: The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and service specifications. Anchor: https://compliance.datasafe.dev/soc2.html#req-pi1-1 PRYV PLATFORM: facilitated (mode: evidence) The canonical event-type schemas (class/format JSON Schemas in the data-types repo) are the machine-readable definition of "data processed", what each event type means and what shape it takes. You extend the catalogue with your own types via the service.eventTypes URL. The processing-objective specifications themselves are your product definitions. HDS: facilitated (effort saved: low) (mode: evidence) The platform's canonical event-type schemas are the machine-readable definition of what data each processing path handles, and the HDS-operated deployment serves these consistently. Authoring the processing-objective specifications — what the service does with the data and to what end — is the service organization's product definition; HDS facilitates by supplying the data-definition substrate. Detail: Event-type schemas define the shape and meaning of data processed, and a deployment can extend the catalogue with custom types. HDS operates the deployment so these definitions are applied uniformly. The processing objectives and service specifications themselves remain the implementer's editorial work; HDS documents the data-quality posture it operates. Evidence: internal:soc2/policies/data-quality Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define and communicate your processing objectives and service specifications; declare the event types your application processes. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 PI1.2 — PI1.2 — Completeness and accuracy of inputs Requirement: The entity implements controls over system inputs, including controls over completeness and accuracy, to result in services that meet its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-pi1-2 PRYV PLATFORM: facilitated (mode: primitive) Input accuracy is enforced structurally at ingest: events.create and events.update run every payload through the event type's JSON Schema (ajv-draft-04), unknown types and schema violations are rejected with HTTP 400, no silent truncation or downgrade. This is the structural-accuracy layer; semantic accuracy (is this the *right* blood-pressure reading) stays in your application. Tighten structural strictness by declaring min/max/pattern in a custom catalogue, see context/data-accuracy-structural-vs-semantic.md. HDS: facilitated (effort saved: medium) (mode: primitive) Input accuracy is enforced structurally at ingest on the HDS-operated platform: every payload is validated against its event-type schema and schema violations are rejected outright, with no silent truncation. This is the structural-completeness-and-accuracy layer; semantic correctness of a value remains the service organization's application logic. Detail: Creates and updates run each payload through the event type's JSON Schema; unknown types and violations are rejected with an error rather than stored partially. HDS operates this validation by default and documents the data-quality and integrity posture. Tighter structural constraints (min/max/pattern) are available via a custom catalogue. Judging whether a structurally valid value is the right value stays with the implementer. Evidence: internal:hipaa/policies/integrity, internal:soc2/policies/data-quality Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define your event types and any tighter structural constraints, and own the semantic-validation logic your application applies on top. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 PI1.3 — PI1.3 — Completeness and accuracy of processing Requirement: The entity implements controls over system processing to result in services that meet its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-pi1-3 PRYV PLATFORM: facilitated (mode: primitive) Pryv's processing model is deterministic + attributable: events are immutable-when-written (history-only append for audit/consent/attestation), events.update snapshots prior state into version history, and every mutation is authorised by the permission model and recorded in the audit log. The business-logic processing your application performs on top is your control responsibility. HDS: facilitated (effort saved: medium) (mode: primitive) The platform's processing model is deterministic and attributable: writes are authorised by the permission model, updates snapshot the prior state into version history, and every mutation is recorded in the per-user audit log. HDS operates this substrate so processing is traceable; the business-logic processing the application performs is the service organization's own control. Detail: Each mutation is gated by per-stream permissions and recorded with its acting access identity; version history preserves prior states so a processing step can be reconstructed and checked. HDS operates and documents this integrity substrate. The application-level processing the implementer builds on top — calculations, transformations, workflows — is its own completeness-and-accuracy responsibility. Evidence: internal:hipaa/policies/integrity Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Implement and document completeness-and-accuracy controls over your own processing logic; rely on the platform substrate for traceability. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 PI1.4 — PI1.4 — Completeness, accuracy, and timeliness of outputs Requirement: The entity implements controls to make available or deliver output completely, accurately, and timely in accordance with specifications to meet its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-pi1-4 PRYV PLATFORM: facilitated (mode: primitive) Output delivery is deterministic: events.get / streams.get return canonical serialisations; the audit log carries an integrity checksum of the affected event when a method mutates one, so output can be tied back to a verified state. Webhooks notify subscribers of change (signal-only, the receiver fetches the authoritative state via authenticated GET, so the delivered output is always the current canonical value). Delivery SLAs to your end recipients are your specification. HDS: facilitated (effort saved: low) (mode: primitive) Output delivery from the HDS-operated platform is deterministic: reads return canonical serialisations of the current authoritative state, and change notifications signal subscribers to fetch that state over an authenticated channel rather than pushing a possibly-stale copy. Delivery SLAs to the implementer's own end recipients are the service organization's specification. Detail: Gets return the canonical value; webhooks notify of change as a signal only, so the receiver always retrieves the current authoritative output. HDS operates this delivery substrate. Defining output specifications and the timeliness commitments to downstream recipients, and verifying they are met, is the implementer's control. Evidence: internal:soc2/policies/data-quality Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define your output specifications and delivery SLAs and verify outputs meet them; the platform supplies the canonical-state delivery substrate. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 PI1.5 — PI1.5 — Completeness and accuracy of stored information Requirement: The entity implements controls to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet its objectives. Anchor: https://compliance.datasafe.dev/soc2.html#req-pi1-5 PRYV PLATFORM: facilitated (mode: storage) Storage integrity: event version history preserves prior states, the audit log can carry a per-event integrity checksum, and backup-restore provides a recoverable copy. Together these give an accuracy + completeness signal for stored data. Tamper-evidence on the audit log itself (hash chaining) is a future primitive, see the CC7.4 chain proposal. HDS: facilitated (effort saved: medium) (mode: storage) Storage integrity on the HDS-operated platform rests on event version history (prior states preserved), the per-user audit log (every change attributed), and operational backup-restore (a recoverable copy). Together these give an accuracy-and-completeness signal for stored data. HDS operates the substrate and runs the backup cycle automatically, verified live on all cores; what is not demonstrated is restore at production scale per region. Detail: Stored data is protected against silent loss by versioning and by the audit trail of every mutation, and against destruction by the backup path HDS operates. Tamper-evidence on the audit log itself (hash chaining) is a future platform primitive. The per-region production restore drill has not been run, so the recoverable-copy half is provisioned rather than proven. HDS documents the integrity posture; the implementer owns the surrounding storage-control procedure. Evidence: internal:hipaa/policies/integrity, internal:hipaa/procedures/data-backup-plan Evidence backing: every internal document cited above has completed approval. PLANNED (platform, impact medium): A hash-chained (tamper-evident) audit log is queued upstream; the tamper-evidence half of this row becomes claimable after it ships and HDS deploys it. IMPLEMENTER [service-organization] coverage: documented applies_when: always Document your storage-integrity controls and retention, and assess the verified-backup gap in your own risk analysis. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P1.1 — P1.1 — Notice of privacy practices Requirement: The entity provides notice to data subjects about its privacy practices to meet its objectives related to privacy, and updates and communicates the notice in a timely manner when those practices change. Anchor: https://compliance.datasafe.dev/soc2.html#req-p1-1 PRYV PLATFORM: facilitated (mode: infrastructure) Pryv gives you the surface to present notice: app-web-auth3 is the forkable consent / auth web page where notice text is shown at authorization time, and the durable access record (with clientData) can carry the notice version the subject saw. Authoring the notice content and keeping it current is your editorial obligation; Pryv carries it through the consent flow and records what was presented. HDS: facilitated (effort saved: medium) (mode: infrastructure) The platform supplies the surface to present notice at authorization time — a forkable consent/auth web page — and the durable access record can carry the notice version the subject saw. HDS operates this surface; authoring the notice content and keeping it current is the service organization's editorial obligation. Detail: Notice text can be shown in the consent flow, and the granted access can record which notice version was presented, giving an evidentiary link between the subject and the practices disclosed. HDS operates the deployment that carries this. The privacy-notice content, its review cadence and its communication on change are the implementer's; HDS documents the consent- flow substrate it provides. Evidence: internal:soc2/policies/privacy-notice IMPLEMENTER [service-organization] coverage: documented applies_when: always Author your privacy notice, present it in the consent flow, and keep it current; record the version each subject was shown. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P2.1 — P2.1 — Choice and consent Requirement: The entity communicates choices regarding the collection, use, retention, disclosure, and disposal of personal information to data subjects and obtains consent, as required, to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p2-1 PRYV PLATFORM: implemented The access IS the durable, versioned consent record: it carries the granted permissions (the scope the subject agreed to), and its clientData holds the consent text / purposes / lawful basis. CMC carries cross-account consent state transitions via typed consent/* events. app-web-auth3 is the choice-presentation UX, and the audit chain proves the consent state at any moment. You design the choices; Pryv records and enforces them. HDS: implemented (effort saved: high) On the HDS-operated platform the access token IS the durable, versioned consent record: it carries the permissions the subject agreed to, its metadata holds the consent text and lawful basis, and the audit trail proves the consent state at any moment. The subject's own credentials let them grant and revoke directly. HDS operates this user-centric consent substrate; the service organization designs the choices presented. Detail: Consent is enforced, not merely recorded: a grant authorises exactly the scope the subject chose and nothing more, and revocation takes effect immediately. The consent-presentation UX is the forkable consent web page, and cross-account consent transitions are captured as typed events. HDS operates and documents this stack as part of its access-control and consent posture. Designing the choice set is the implementer's product decision. Evidence: internal:hipaa/policies/access-control, internal:soc2/policies/privacy-notice IMPLEMENTER [service-organization] coverage: documented applies_when: always Design the choices you present and the consent text, and map each choice to the access scope it grants; the platform records and enforces it. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P3.1 — P3.1 — Collection consistent with objectives Requirement: Personal information is collected consistent with the entity's objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p3-1 PRYV PLATFORM: facilitated (mode: primitive) Collection scope is bounded by the access's permissions, an app can only write to the streams + levels it was granted (e.g. create-only on a specific subtree), so collection cannot silently exceed the agreed purpose. Defining the purpose and the minimal stream set is your data-model design; the boundary is enforced. HDS: facilitated (effort saved: medium) (mode: primitive) Collection scope is bounded technically by the access token's permissions on the HDS-operated platform: an application can only write to the streams and levels it was granted, so collection cannot silently exceed the agreed purpose. HDS operates this enforcement; defining the purpose and the minimal stream set is the service organization's data-model design. Detail: A create-only grant on a specific subtree means an app collects only into that subtree at that level — over-collection is structurally prevented rather than policed after the fact. HDS operates and documents this minimum-necessary posture. The implementer designs which streams and grants correspond to which collection purpose. Evidence: internal:hipaa/policies/minimum-necessary, internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [connects] Define each collection purpose and the minimal stream set it needs, and grant only that scope; document the mapping. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [connects]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: [connects]; PLACES NO DUTY ON THIS PERSONA ## soc2 P3.2 — P3.2 — Explicit consent for sensitive personal information Requirement: Explicit consent for the collection, use, retention, disclosure, and disposal of sensitive personal information is obtained from data subjects or other authorized persons, if required. Anchor: https://compliance.datasafe.dev/soc2.html#req-p3-2 PRYV PLATFORM: facilitated (mode: primitive) Sensitive data can be isolated in dedicated streams gated by a distinct access whose clientData records the explicit-consent basis; consent/* events capture the state transition with a timestamp. The "explicit" UX (a separate, affirmative consent step) is yours to present; Pryv records it as a distinct, auditable grant rather than folding it into general consent. HDS: facilitated (effort saved: medium) (mode: primitive) Sensitive data can be isolated in dedicated streams gated by a distinct access whose metadata records the explicit-consent basis, with the consent state transition captured as a timestamped, auditable event. HDS operates this isolation; presenting the separate, affirmative consent step is the service organization's UX obligation. Detail: The platform records explicit consent as a distinct, auditable grant rather than folding it into general consent, so a sensitive-data grant is separable in evidence. HDS operates and documents the access-control substrate. The "explicit" step — a separate affirmative action — is the implementer's to present; the platform records it discretely. Evidence: internal:hipaa/policies/access-control, internal:soc2/policies/privacy-notice IMPLEMENTER [service-organization] coverage: documented applies_when: [connects, analytics, secondary-use] Present a separate affirmative consent step for sensitive data and gate that data behind a distinct access; document the explicit-consent flow. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [connects, analytics, secondary-use]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: [connects, analytics, secondary-use]; PLACES NO DUTY ON THIS PERSONA ## soc2 P4.1 — P4.1 — Use limited to identified purposes Requirement: The entity limits the use of personal information to the purposes identified in its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p4-1 PRYV PLATFORM: facilitated (mode: primitive) Purpose limitation is the permission model's core job: a credential issued for purpose A (scoped to stream A) cannot read or write purpose-B data. The audit log evidences that uses stayed within scope. Mapping purposes to streams + accesses is your design; the enforcement is technical, not policy-on-paper. HDS: implemented (effort saved: high) Purpose limitation is the core job of the permission model HDS operates: a credential issued for one purpose, scoped to one set of streams, cannot read or write data for another purpose, and the audit log evidences that uses stayed within scope. Enforcement is technical, on every API call, not policy-on-paper. Mapping purposes to streams and accesses is the service organization's design. Detail: A purpose-A credential is mechanically incapable of touching purpose-B data, and every use is recorded against its acting access identity so adherence is auditable. HDS operates and documents this minimum-necessary and access-control posture. The implementer decides which purposes exist and how they map to scopes. Evidence: internal:hipaa/policies/minimum-necessary, internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [connects, analytics] Map each identified purpose to a distinct access scope and document the mapping; the platform enforces the boundary. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [connects, analytics]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: [connects, analytics]; PLACES NO DUTY ON THIS PERSONA ## soc2 P4.2 — P4.2 — Retention of personal information Requirement: The entity retains personal information consistent with its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p4-2 PRYV PLATFORM: facilitated (mode: storage) Retention metadata (period, basis, scheduled disposal date) can ride on event / access clientData so each record carries its own retention contract. Pryv ships no automatic TTL / expiry primitive, enforcement of the retention schedule is an operator job today (a scheduled sweep calling events/streams delete). The retention policy itself is yours; treat the absence of auto-expiry as an operator responsibility when you attest P4.2. Detail: This is **voluntarily missing + operator-owned** by design, the same classification as GDPR Art.5(1)(e) storage limitation. Pryv stays retention-policy-neutral: no TTL / auto-delete / scheduler primitive ships, so automatic disposal is the operator's external scheduled job composing existing primitives (`events.get toTime=` + two-stage `events.delete` + `streams.delete` + `auth.delete`, with the audit log as the inactivity oracle). `clientData.retention` is advisory metadata, not an enforcement hook; every retention deletion is itself audit-logged. Full rationale + the recommended operator retention-job pattern in `context/data-retention-operator-owned.md`. HDS: facilitated (effort saved: low) (mode: storage) Retention metadata (period, basis, scheduled disposal date) can ride on each record so it carries its own retention contract, but the platform ships no automatic expiry primitive — enforcing the schedule is an operator job today. HDS documents this gap honestly: automated retention enforcement is not yet shipped, so the control is facilitated and the absence of auto-expiry is called out. Detail: Each record can record its retention terms, but a scheduled sweep that deletes expired records must be operated rather than relied on as a platform feature. HDS treats formal, automated data-retention as a known gap being matured and documents the retention posture and its limit. The retention policy itself, and its enforcement, are the implementer's responsibility when attesting this criterion. Evidence: internal:soc2/procedures/data-retention-and-disposal PLANNED (doc, impact low): The retention-and-disposal procedure (documented retention schedule over the per-record metadata) is drafted in the internal pipeline; its formalisation is the tracked remediation. IMPLEMENTER [service-organization] coverage: documented applies_when: [analytics] Define your retention schedule, record retention terms on each record, and operate the enforcement sweep yourself; document the absence of platform auto-expiry as your responsibility. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [analytics]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: [analytics]; PLACES NO DUTY ON THIS PERSONA ## soc2 P4.3 — P4.3 — Disposal of personal information Requirement: The entity securely disposes of personal information to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p4-3 PRYV PLATFORM: configurable Disposal uses the per-user erasure path: system.users.delete for whole-account, event/stream deletion for per-record. Backup reach is engine-dependent (SQLite per-user file unlink vs PostgreSQL row + pg_dump rotation), choose the engine that matches your disposal commitment, same as GDPR Art.17. HDS: facilitated (effort saved: medium) (mode: storage) Disposal uses the platform's per-user erasure path (whole-account deletion, plus event- and stream-level deletion) from the live store, which HDS operates. Backup reach is storage-engine-dependent and scheduled disposal automation is not yet shipped, so HDS facilitates this and documents the boundary rather than claiming full secure disposal. Detail: Logical erasure from the live store is concrete; whether it reaches backups depends on the configured engine, and a documented, verified disposal schedule is a known gap. HDS documents the disposal path and its limits, and relies on the hosting provider for physical media sanitisation. The implementer chooses the engine that matches its disposal commitment. Evidence: internal:soc2/procedures/data-retention-and-disposal, internal:hipaa/policies/minimum-necessary PLANNED (doc, impact low): The retention-and-disposal procedure (documented schedule, verified backup pruning) is drafted in the internal pipeline; its formalisation is the tracked remediation for the disposal half of this row. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define your disposal procedure, choose a storage engine whose backup behaviour matches it, and document how disposal reaches all copies. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: always The hosting subservice carries physical media sanitisation; obtain and record its attestation. ## soc2 P5.1 — P5.1 — Data subject access to personal information Requirement: The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, on request, provides copies to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p5-1 PRYV PLATFORM: implemented Subject access is subject-runnable: the data subject holds their own credentials, so events.get / streams.get return their data directly, and the pryv-account-backup CLI produces a complete portable export, account, profiles, app profiles, streams, accesses (incl. revoked / expired + opt-in per-access version history), events (chunked + incremental), audit log, HF series data points, webhooks, and attachments, with a per-file sha256 integrity manifest, with no operator dependency for routine requests. The browser-based webapp flavour covers the read-side text resources only; route subjects who need attachments / HF series / webhooks to the CLI. See context/account-backup-coverage.md. HDS: implemented (effort saved: high) Subject access is user-centric and subject-runnable on the HDS-operated platform: the data subject holds their own credentials, so reads return their data directly, and an account-backup export produces a complete, portable copy with a per-file integrity manifest — with no operator dependency for routine requests. HDS operates this substrate; the service organization owns the identity-verification step for any operator-assisted request. Detail: Because the subject is the holder of their own access, review and export are self-service. The export covers account, streams, accesses (including revoked/expired with version history), events, audit log, and attachments, with a sha256 manifest per file. HDS operates the deployment and documents the access posture. Packaging a non-routine request and verifying the requester's identity is the implementer's workflow. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Surface the self-service access and export paths to subjects, and document your identity-verification step for any operator-assisted request. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P5.2 — P5.2 — Correction, amendment, or appending of personal information Requirement: The entity corrects, amends, or appends personal information based on data subject input and communicates such changes to third parties, as committed or required, to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p5-2 PRYV PLATFORM: implemented Correction is events.update (which snapshots the prior value into version history, preserving the amendment trail) and account.update for profile fields; the audit log records who amended what, when. Propagation to third parties who hold a shared/CMC access can use webhooks to signal the change. Judging the correctness of a correction request is your process. HDS: implemented (effort saved: medium) Correction is a first-class operation on the HDS-operated platform: an update snapshots the prior value into version history (preserving the amendment trail) and the audit log records who amended what, when. Propagation to third parties holding a shared access can be signalled via change notification. Judging whether a correction request is valid is the service organization's process. Detail: Amendments preserve, rather than overwrite, the record's history, so the correction trail is intact and attributable. Third parties who hold a shared grant can be notified of the change and fetch the corrected state. HDS operates and documents the integrity and access substrate. Deciding the correctness of a request and committing to third-party communication is the implementer's. Evidence: internal:hipaa/policies/integrity, internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Define your process for assessing correction requests and your commitments to notify third parties of amendments. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P6.1 — P6.1 — Disclosure to third parties for identified purposes with consent Requirement: The entity discloses personal information to third parties for the purposes identified in its objectives related to privacy and with the explicit consent of the data subject, if required. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-1 PRYV PLATFORM: facilitated (mode: primitive) Third-party disclosure happens by issuing a scoped shared / CMC access, the disclosure is exactly the permissions granted, nothing more, and the access's clientData records the purpose + consent basis. There is no out-of-band data-dump path; disclosure is always a tracked, revocable grant. Deciding the lawful purpose is yours. HDS: facilitated (effort saved: medium) (mode: primitive) Third-party disclosure on the HDS-operated platform happens by issuing a scoped, revocable shared access — the disclosure is exactly the permissions granted, nothing more, with the purpose and consent basis recorded in the access metadata. There is no out-of-band data-dump path; every disclosure is a tracked, revocable grant. Deciding the lawful purpose is the service organization's. Detail: Disclosure being a grant rather than a copy means the recipient's reach is bounded and reversible, and the grant itself carries the why. HDS operates and documents this access-control posture. The implementer decides the lawful purpose and obtains any required explicit consent before issuing the grant. Evidence: internal:hipaa/policies/access-control, internal:hipaa/policies/minimum-necessary Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Decide the lawful purpose, obtain any required explicit consent, and issue a scoped shared access for each disclosure; document the basis. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P6.2 — P6.2 — Record of authorized disclosures Requirement: The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-2 PRYV PLATFORM: implemented Every disclosure is a read against a shared / CMC access, and the per-user audit log records each access invocation with the accessId + accessSerial that made it, a complete, attributable record of who accessed what, when. Since open-pryv.io `07b6d3b6` the *authorization* of a disclosure is recorded too: OAuth2 `oauth.*` audit events capture the consent grant, the code exchange and every token issuance / refresh / revocation that underlie a delegated-app disclosure. The audit-event-stream can surface the same record into the subject's own streams. This is the technical disclosure register; how long you retain it is your policy. HDS: implemented (effort saved: high) Every disclosure is a read against a shared access, and the per-user audit log records each invocation with the access identity that made it — a complete, attributable record of who accessed what, when. HDS operates and retains this disclosure register; how long it is retained is set per the service organization's policy. Detail: The authorized-disclosure register is computable directly from the audit log plus the list of granted accesses, with no separate logging to maintain. HDS operates the substrate and documents the access and audit-controls posture. The implementer sets the retention period for the register consistent with its privacy objectives. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Set and document the retention period for the disclosure register and the cadence at which you review it. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P6.3 — P6.3 — Record of detected unauthorized disclosures Requirement: The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures, including breaches, to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-3 PRYV PLATFORM: facilitated (mode: evidence) The audit log captures access patterns (including failed / out-of-scope attempts), and observability surfaces anomalies, so a detected unauthorized disclosure has a contemporaneous evidentiary record. Detecting that a disclosure was unauthorized (vs authorized) is your assessment; Pryv supplies the raw trail. HDS: facilitated (effort saved: medium) (mode: evidence) The audit log captures access patterns including failed and out-of-scope attempts, and HDS's infrastructure monitoring surfaces anomalies, so a detected unauthorized disclosure has a contemporaneous evidentiary record. Determining that a disclosure was unauthorized, and maintaining the formal record, is the service organization's assessment. Note that logs may contain PII, which HDS documents as a known handling consideration. Detail: HDS operates the audit and monitoring substrate that gives an unauthorized disclosure a timestamped trail, and runs alerting end to end before any component is treated as production. Classifying an event as unauthorized and keeping the breach record is the implementer's process. HDS documents the detection posture and the gap that log content is not yet PII-minimised. Evidence: internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. PLANNED (feature, impact medium): PHI-safe log handling for operator telemetry is the tracked remediation: HDS-authored services are moving to an allow-list observability library feeding a self-hosted collector, replacing the deny-list scrubbing over a vendor agent; the live exception is recorded in the subprocessor register. IMPLEMENTER [service-organization] coverage: documented applies_when: always Classify detected events as authorized or not, and create and retain the unauthorized-disclosure record within your incident process. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P6.4 — P6.4 — Third-party commitments for privacy Requirement: The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-4 PRYV PLATFORM: out-of-scope Vendor / subprocessor privacy commitments are contractual artefacts (DPAs, BAAs). No software role, though when the third party's technical access is a Pryv shared/CMC access, the permission scope is a concrete, enforced bound on what they were given, which your DPA can reference. HDS: facilitated (effort saved: medium) (mode: evidence) Vendor and subprocessor privacy commitments are contractual. HDS obtains such commitments from its own subprocessors and tracks them in a register, and where a third party's technical access is a shared access, its permission scope is a concrete, enforced bound the implementer's agreement can reference. Executing the implementer's own third-party agreements is its responsibility. Detail: HDS maintains a current subprocessor register with privacy commitments flowed down, available to the implementer for its own due diligence. The access scope of any third party that holds a platform grant is a technical, auditable limit that complements the contractual commitment. The implementer obtains and retains its own vendor commitments. Evidence: internal:hipaa/registers/subprocessor-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [third-parties] Obtain and retain privacy commitments from your own vendors and third parties; reference the enforced access scope where applicable. Templates to sign: subprocessor IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [third-parties]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [third-parties] Provide your privacy commitments to the service organization and flow them to any of your own downstream parties. ## soc2 P6.5 — P6.5 — Third-party unauthorized disclosure response Requirement: The entity obtains commitments from vendors and third parties to notify it of actual or suspected unauthorized disclosures, and responds to such notifications, to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-5 PRYV PLATFORM: out-of-scope The third-party notification commitment is contractual and the response is your incident process (see CC7.4). No software role at the vendor-commitment layer. HDS: facilitated (effort saved: low) (mode: evidence) The third-party notification commitment is contractual, and HDS commits to notifying its implementers of incidents affecting their data, backed by its monitoring and incident-response programme. Obtaining the same commitment from the implementer's own third parties, and responding to notifications, is the service organization's process. Detail: HDS flows a notification obligation to its own subprocessors and carries one to its implementers; the detection and forensic evidence behind it comes from the audit and monitoring substrate. The implementer obtains equivalent commitments from its vendors and runs its own response when notified (see CC7.4-equivalent incident handling). Evidence: internal:hipaa/procedures/security-incident-response, internal:hipaa/registers/subprocessor-register Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: [third-parties] Obtain notification commitments from your third parties and run your response process when notified. Templates to sign: subprocessor IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: [third-parties]; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: documented applies_when: [third-parties] Commit to notify the service organization of suspected unauthorized disclosures and flow the same down your chain. ## soc2 P6.6 — P6.6 — Notice of breaches and incidents to affected parties Requirement: The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-6 PRYV PLATFORM: facilitated (mode: evidence) Pryv contributes the scoping evidence a breach notice needs, the audit log ties a compromised access to the user + data it touched. The shipped `bin/breach-scope.js` (accessId → user reverse-index + audit `recordCount` + `scopedStreamIds` query scope) automates "who was affected, how many records, which streams in scope" in one command. Drafting and sending the notifications within the regulatory deadline is your process. PLANNED (feature, impact low): Chained audit log raises forensic confidence in the breach-scope determination HDS: facilitated (effort saved: medium) (mode: evidence) The platform supplies the scoping evidence a breach notice needs — the audit log ties a compromised access to the users and data it touched — and HDS operates the monitoring and incident-response programme that detects and scopes the event. Drafting and sending the notifications within the regulatory deadline is the service organization's process. Detail: HDS operates the detection-and-scoping substrate (audit plus monitoring, with alerting wired end to end) so a breach has a contemporaneous, attributable record of who was affected. The reverse-index from a compromised access to affected subjects is now a deployed platform primitive, not a manual step: `GET /system/accesses/:accessId` resolves a compromised access to its owner in O(1) over a cluster-wide index, and `bin/breach-scope.js` emits the affected-subjects/data report from the audit + access-version data (deployed on all HDS cores 2026-07-29). The implementer drafts and sends the breach notices and meets the regulatory clock; HDS's incident procedure governs the report it produces. Evidence: internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Own the breach-notification workflow — assess scope, draft and send notices to subjects and regulators within the applicable deadlines. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P6.7 — P6.7 — Accounting of disclosures to data subjects Requirement: The entity provides data subjects, on request, with an accounting of the personal information held and the disclosures of their personal information, to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p6-7 PRYV PLATFORM: implemented The accounting-of-disclosures answer is computable from the audit log (which accesses read which data, when) plus the accesses list (who holds a grant). The audit-event-stream can expose this to the subject directly. Packaging it into a subject-facing report on request is your workflow; the underlying record is complete and attributable. HDS: implemented (effort saved: medium) The accounting-of-disclosures answer is computable from the audit log (which accesses read which data, when) plus the list of granted accesses (who holds a grant) on the HDS-operated platform. HDS operates the substrate; packaging it into a subject-facing report on request is the service organization's workflow. Detail: Because every disclosure read and every grant is recorded, the underlying accounting record is complete and attributable without separate bookkeeping. HDS operates and documents the audit and access posture. The implementer formats the accounting into a subject-facing response and verifies the requester's identity. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Package the audit-derived accounting into a subject-facing report on request and verify the requester's identity. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P7.1 — P7.1 — Data quality — accuracy, completeness, relevance Requirement: The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p7-1 PRYV PLATFORM: facilitated (mode: primitive) Structural data quality is enforced at ingest by event-type schema validation (HTTP 400 on malformed input); subjects keep their data up-to-date via events.update / account.update (with version history). "Relevant", collecting no more than the purpose needs, is bounded by the permission scope you grant. Judging semantic accuracy of a specific value is your application's responsibility. HDS: facilitated (effort saved: medium) (mode: primitive) Structural data quality is enforced at ingest by event-type schema validation (malformed input rejected), subjects keep their data current via updates with version history, and "relevant" is bounded by the access scope granted. HDS operates these primitives; judging the semantic accuracy of a specific value is the service organization's application responsibility. Detail: Completeness and structural accuracy are enforced by validation; relevance is enforced by minimum-necessary scoping; currency is supported by subject-driven updates that preserve history. HDS operates and documents the data-quality posture. Semantic correctness — is this the right value — stays with the implementer's application logic. Evidence: internal:soc2/policies/data-quality, internal:hipaa/policies/minimum-necessary Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [service-organization] coverage: documented applies_when: always Own semantic-accuracy validation in your application, surface update paths to subjects, and scope collection to what each purpose needs. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA ## soc2 P8.1 — P8.1 — Privacy complaint management and compliance monitoring Requirement: The entity implements a process for receiving, addressing, resolving, and communicating the resolution of privacy inquiries, complaints, and disputes, and periodically monitors compliance, taking timely corrective action on identified deficiencies, to meet its objectives related to privacy. Anchor: https://compliance.datasafe.dev/soc2.html#req-p8-1 PRYV PLATFORM: facilitated (mode: evidence) The complaint-handling workflow is yours, but Pryv supplies the monitoring evidence (audit + observability) and can host the complaint / resolution records themselves as events on a dedicated stream with an attributable trail. This compliance matrix doubles as the periodic control-inventory you monitor against. HDS: facilitated (effort saved: low) (mode: evidence) The complaint-handling workflow is the service organization's, but the HDS-operated platform supplies the monitoring evidence (audit plus infrastructure monitoring) and can host the complaint and resolution records themselves as events on a dedicated stream with an attributable trail. This compliance matrix doubles as the periodic control inventory the implementer monitors against. Detail: HDS operates the audit and monitoring substrate that evidences ongoing compliance, and the platform can store complaint/resolution records as first-class, attributable data. HDS documents the monitoring posture. The receiving, addressing, resolving and communicating process — and the periodic compliance review with corrective action — is the implementer's. Evidence: internal:soc2/policies/privacy-notice IMPLEMENTER [service-organization] coverage: documented applies_when: always Run your complaint-handling and periodic-compliance-monitoring process, and take timely corrective action; the platform can host the records. IMPLEMENTER [user-entity] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [subservice-organization] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA # Swiss Federal Act on Data Protection (revised FADP / nLPD) (swiss-nlpd) regulation · Switzerland (extraterritorial via Art. 3 for processing affecting CH) · SR 235.1 (revFADP / nLPD, in force 2023-09-01) · regions: ch Official text: https://www.fedlex.admin.ch/eli/cc/2022/491/en HDS's own position on Swiss nLPD: - vault: HDS is 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. External assurance: self-assessed. No FDPIC review, no certification under Art.13 nLPD and no independent audit has been performed. This is HDS's own assessment. Nothing is on file for the Swiss hosting region either: the physical safeguards HDS inherits there are asserted by the provider, not evidenced by a third-party audit. Evidence: 11 of 30 requirements answered from approved HDS documentation (24 cite internal evidence), as of 2026-09-10. 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. NOTE: 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. Known gaps in HDS's own position: - [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. - [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. (refs: 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. ## swiss-nlpd Art.5 — Definitions Requirement: Defines key terms including personal data, sensitive personal data, processing, controller and processor. The nLPD's sensitive-data category is broader than GDPR Art. 9, adding social-assistance measures and data on administrative or criminal proceedings and sanctions. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-5 PRYV PLATFORM: facilitated (mode: primitive) The same primitive mapping that handles GDPR Art. 4 carries here (event = personal data, access = consent / authorization, etc.). The Swiss- specific item is the broader "sensitive personal data" category: implementer responsibility to design the stream layout so social-assistance / administrative-proceeding data sit on streams permissioned at the heightened-protection scope you apply to it. Detail: Practical Pryv pattern: dedicate stream subtrees per sensitive- data category (e.g., `health/`, `social-assistance/`, `criminal-record/`), and grant accesses with `permissions[]` restricted to the smallest necessary subtree. Sensitive-data classification of a category is a written editorial decision, Pryv carries the classification but doesn't assign it. HDS: facilitated (effort saved: medium) (mode: primitive) On top of Pryv's primitive model, HDS operates the platform and designs the vault's stream layout. The classification of a data category as sensitive, including the nLPD's broader categories, is a judgement for whoever processes the data, and HDS carries the cited classification into the access and audit record. Detail: The layout dedicates separate stream subtrees per sensitive-data category, and accesses are granted scoped to the smallest necessary subtree, so the heightened-protection posture follows the topology. An organisation requests a scope no wider than its categories need; the vault's topology is not its to design, and the sensitivity classification is not HDS's to assign. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Classify the data categories you handle, including the nLPD's broader sensitive categories, and request permission scopes no wider than those categories need. The vault's stream topology is not yours to design. IMPLEMENTER [processor] coverage: documented applies_when: always Process the categories the controller designates only as instructed. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.6 — Principles of processing Requirement: Processing must be lawful, in good faith and proportionate. Personal data may be collected only for a purpose recognisable to the data subject; accuracy must be ensured and data destroyed or anonymised when no longer needed. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-6 PRYV PLATFORM: implemented Same Pryv contributions as GDPR Art. 5: permissions enforce purpose-limitation technically; audit + access versioning give the accountability artefact; events.update with version history addresses accuracy. The Swiss-specific "recognisability" criterion (purpose recognisable to the subject at collection) maps to the consent UX layer, where the purpose written into `access.clientData.purpose` should be the same purpose presented to the subject. Detail: Storage limitation: see Art.17-equivalent (GDPR Art.17 erasure; revFADP Art. 32 §2 lit c on data destruction when no longer needed). The configurable erasure mechanics from `gdpr.Art.17` apply equivalently. HDS: implemented (effort saved: high) HDS operates the platform whose permission model enforces purpose limitation technically and whose audit log and access version history provide the accountability artefact. Event update with version preservation supports the accuracy duty. The substantive purpose and proportionality judgements remain the controller's. Detail: The purpose written into the access client-data should mirror the purpose presented to the data subject, satisfying the nLPD's recognisability criterion as a durable record. Storage limitation is operated through the same erasure mechanics described under Art. 32; automated retention enforcement is a known gap that the controller must cover by process. Evidence: internal:hipaa/policies/minimum-necessary, internal:hipaa/policies/access-control, internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Determine the lawful purpose, present it recognisably at collection, and define a retention and destruction policy. IMPLEMENTER [processor] coverage: documented applies_when: always Process only within the controller's stated purpose and instructions. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You exercise rectification through the platform; prior versions are preserved. ## swiss-nlpd Art.7 — Data protection by design and by default Requirement: The controller must ensure, from planning through implementation, that processing complies with the Act through suitable technical and organisational measures, with privacy-protective default settings. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-7 PRYV PLATFORM: facilitated (mode: infrastructure) Pryv's architecture is designed to satisfy Art. 7's "from planning through implementation" directive, per-user storage isolation, stream- scoped permissions, separate personal/app/shared access types, system streams for privileged data, audit-by-default. What stays on the implementer is the per-deployment default configuration (token scopes minted, retention chosen, notice shown at registration). HDS: facilitated (effort saved: high) (mode: infrastructure) The Pryv architecture HDS operates is privacy-protective by construction: per-user storage isolation, stream-scoped permissions, distinct access types, system streams for privileged data and audit-by-default. HDS runs this baseline and sets the vault's own defaults, including what is presented at registration. Detail: What stays with an organisation is the defaults in what it builds: how narrow a grant it requests, its own retention, and its own collection notice. Vault registration and the notices shown there belong to HDS, which supplies and operates the privacy-by-design substrate those choices configure. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Set privacy-protective defaults in what you deploy: the narrowest grant you request, your own retention policy, and your own collection notice. Vault registration and its notices belong to HDS. IMPLEMENTER [processor] coverage: documented applies_when: always Operate within the design and defaults the controller sets. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.8 — Data security Requirement: The controller and processor must ensure data security through appropriate technical and organisational measures; the Federal Council may set minimum requirements through the Ordinance on Data Protection. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-8 PRYV PLATFORM: facilitated (mode: infrastructure) Pryv contributes the same multi-aspect technical baseline as for GDPR Art. 32: TLS in transit (letsEncrypt-integration); operator-side at-rest encryption; AES-256-GCM for at-rest operator secrets; stream- scoped permissions; MFA; multi-core HA via rqlite; `bin/backup.js` restoration. The OPDP minimum-requirements detailing remains the operator's compliance verification work. HDS: facilitated (effort saved: high) (mode: infrastructure) HDS operates the technical security baseline: TLS in transit, stream-scoped permissions, MFA, multi-core high availability, operated backup and restore, and at-rest encryption of the event store via hosting-layer volume encryption (in place since 2026-06-26; provider-managed keys — the accepted residual is recorded in the cited risk record). Detail: The OPDP minimum-requirements detailing and the organisational measures remain the controller's and processor's compliance work. HDS supplies the technical and hosting safeguards and operates them; at-rest volume encryption covers stored event data, with provider-held keys as the documented residual (operator-held-key or end-to-end encryption remain optional strengthenings). Evidence: internal:hipaa/policies/transmission-security, internal:hipaa/policies/encryption, internal:hipaa/risk/at-rest-encryption, internal:hipaa/evidence/at-rest-encryption-verification Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Assess whether the operated measures meet your security obligation, weighing the provider-managed-key residual at rest, and add organisational measures. IMPLEMENTER [processor] coverage: documented applies_when: always Ensure equivalent security for any processing you perform and report measures to the controller. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.19 — Information duty when collecting personal data Requirement: The controller must inform the data subject of any acquisition of personal data, whether collected from the subject or from a third party, including controller identity, purpose, recipients and any transfer abroad. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-19 PRYV PLATFORM: facilitated (mode: storage) Same mapping as GDPR Art. 13/14: notice text lives in `access.clientData.privacy_notice` (or a dedicated `consent/*` event when CMC is in play), preserved immutably. The customer- facing `app-web-auth3` template is the surface where the notice is typically shown. Pryv records what you presented; presentation itself is your editorial responsibility. Detail: revFADP Art. 19 unifies the GDPR Art. 13 (direct collection) and Art. 14 (indirect collection) into a single information duty. The Pryv artefact set is the same, `access.clientData` + provenance metadata on event.clientData when data didn't come from the subject directly. HDS: facilitated (effort saved: medium) (mode: storage) HDS preserves the notice text presented to each data subject as client-data on the relevant access or as a dedicated consent event, so what was shown is recoverable per subject and per time. The notice content and its presentation are the controller's editorial responsibility. Detail: The nLPD unifies direct and indirect collection into a single information duty; where data did not come from the subject, provenance metadata on the event client-data records the source. HDS stores these artefacts; presenting the notice is the controller's. Evidence: internal:hipaa/policies/notice-of-privacy-practices, internal:gdpr/policies/lawful-basis-and-consent IMPLEMENTER [controller] coverage: documented applies_when: [connects, own-records] Author the information notice, present it at collection and record the source where data is acquired indirectly. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.21 — Automated individual decisions Requirement: The controller must inform the data subject of a decision based exclusively on automated processing that has a legal effect or significantly affects them; the subject may state their view. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-21 PRYV PLATFORM: facilitated (mode: evidence) Automated decisioning is the implementer's application logic, not Pryv's. What Pryv contributes: the audit log lets you record when automated- decision processing ran and on which input data, and `events` are the carrier for the subject's expressed view (e.g., a `decision/objection` event on a designated stream). HDS: facilitated (effort saved: low) (mode: evidence) Automated decisioning is the controller's application logic, not HDS's. HDS contributes the audit log, which records when automated-decision processing ran and on which inputs, and events as the carrier for the subject's expressed view. Detail: A typical pattern records the subject's objection or statement as a dedicated event on a designated stream, time-anchored by the audit log. The decision logic and the duty to inform are the controller's. Evidence: internal:hipaa/procedures/security-incident-response Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [analytics] Identify exclusively-automated decisions, inform the subject and offer the opportunity to state a view. IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You may record your view on an automated decision as an event. ## swiss-nlpd Art.22 — Data protection impact assessment Requirement: The controller must carry out a data protection impact assessment in advance where processing may entail a high risk to the personality or fundamental rights of the data subject. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-22 PRYV PLATFORM: facilitated (mode: evidence) The DPIA itself is a written assessment artefact that you (the controller) produce. Pryv contributes to its inputs: the data-residency primitive tells you where each subject's data lives; audit + access-version data describe the processing-flow technical layer with concrete artefacts; system-streams isolation gives a defensible "scope of sensitive data" boundary. The legal-side methodology + the writing of the assessment remain yours. HDS: facilitated (effort saved: low) (mode: evidence) The DPIA is a written assessment the controller produces. HDS contributes its inputs: data residency tells you where each subject's data lives, the audit and access-version data describe the processing-flow technical layer, and system-stream isolation gives a defensible sensitive-data boundary. Detail: The methodology and the writing of the assessment remain the controller's. HDS supplies concrete technical artefacts that populate the data-flow and residency sections of the DPIA. Evidence: internal:gdpr/registers/records-of-processing, internal:gdpr/procedures/dpia IMPLEMENTER [controller] coverage: documented applies_when: [analytics] Determine when a DPIA is required, run it, and use the platform artefacts as inputs. IMPLEMENTER [processor] coverage: documented applies_when: [analytics] Assist the controller's DPIA with information about your processing. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.24 — Notification of data security breaches Requirement: The controller must notify the Federal Data Protection and Information Commissioner of a breach likely to result in a high risk to the personality or fundamental rights of the data subject as soon as possible; subject notification is required only where needed for their protection or on the Commissioner's request. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-24 PRYV PLATFORM: facilitated (mode: evidence) Same Pryv contribution as GDPR Art. 33: the shipped `bin/breach-scope.js` toolchain + audit data + access-version chain let you scope the breach (which subject, which streams in scope, by which access). The Swiss-specific point: revFADP Art. 24 says "as soon as possible" rather than GDPR's 72-hour hard cap, but the FDPIC 2025-02-06 guideline still expects "immediately" for high-risk breaches. Plan your incident-response cadence to match either regime if you face both. Detail: The downstream subject-notification trigger differs from GDPR (revFADP Art. 24 makes it more conditional). Your incident- response decision matrix should encode: "high risk to subject? → notify FDPIC immediately + assess whether subject notification necessary for their protection". Pryv data feeds both the risk assessment (audit scope of access) and the safe-harbor determination (was the leaked artefact encrypted at rest?). HDS: facilitated (effort saved: medium) (mode: evidence) HDS operates the audit log and access version chain that let the controller scope a breach — which subjects, which streams, by which access — now automated by the deployed breach-scope primitive (`bin/breach-scope.js` + `GET /system/accesses/:accessId`, on all HDS cores since 2026-07-29). The nLPD's "as soon as possible" timeline is the controller's to meet; HDS provides the underlying scoping evidence. Detail: HDS notifies the parties affected of breaches it detects, as controller of the vault rather than as anyone's processor, so that whoever carries a Commissioner-notification duty can meet it. The scoping report (compromised access to owner, affected subjects and streams, scoped exposure) is emitted by bin/breach-scope.js from the audit and access-version data. The subject-notification trigger is more conditional than under the GDPR; an organisation facing both regimes should encode both in its incident-response matrix. The event store is encrypted at rest by hosting-layer volume encryption since 2026-06-26, which strengthens the safe-harbour assessment of a leaked at-rest artefact: a lost or decommissioned medium is protected, while a live-system compromise reaches decrypted content and is assessed on its facts. Evidence: internal:hipaa/procedures/security-incident-response, internal:gdpr/procedures/breach-notification-72h, internal:hipaa/risk/at-rest-encryption IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy] Run the risk assessment, notify the Commissioner as soon as possible and assess whether subject notification is required. IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy] Notify the controller of breaches without undue delay and assist scoping. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.25 — Right to information (data-subject access) Requirement: A data subject may request information from the controller as to whether personal data about them is processed, with the information needed to assert their rights — purpose, categories, recipients, retention, source and any automated decisions. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-25 PRYV PLATFORM: implemented Same implementation as GDPR Art. 15: subject holding a personal token reads everything via the standard Pryv API (events, streams, accesses with history, audit, attachments) in the canonical data-types JSON shape. revFADP Art. 25 §2 lists an extended minimum-information set (purpose, categories, recipients, retention, source, automated decisions), same artefacts as GDPR + a Swiss-specific "source" duty that maps to `event.clientData.source` when data wasn't from the subject directly. HDS: implemented (effort saved: high) Pryv is user-centric: the data subject, holding a personal token, reads everything through the standard API — events, streams, accesses with history, audit records and attachments — in canonical JSON. HDS operates this access capability end-to-end and ships the app-portability self-service web app (portability.hds.ngo) so subjects can obtain a full account dump without operator involvement. Detail: The nLPD's extended minimum-information set maps onto the same artefacts as a GDPR access request, plus a Swiss-specific source duty satisfied by the provenance recorded on event client-data when data did not come from the subject directly. The response timeline is the controller's process target. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, doc:https://github.com/healthdatasafe/app-portability, internal:gdpr/procedures/data-subject-rights, internal:hipaa/procedures/security-incident-response IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You access your own data directly through the standard API or a portal built on it. IMPLEMENTER [controller] coverage: documented applies_when: [connects] Operate the request process for the data you hold, meet the response timeline and supply the extended minimum-information set. For data still in the vault the individual asks HDS directly. IMPLEMENTER [processor] coverage: documented applies_when: [connects] Make data available to the controller to satisfy access requests. Templates to sign: dpa ## swiss-nlpd Art.28 — Right to data portability Requirement: The data subject has the right to receive personal data they have provided to the controller in a commonly used electronic format and to have it transmitted to another controller where feasible. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-28 PRYV PLATFORM: implemented Same implementation as GDPR Art. 20: `events.get` + `streams.get` return canonical JSON validated against `data-types` schemas. For controller-to-controller transmission (§2), the CMC capability- access flow mints a URL the receiving controller can read; no operational lift on the subject's side. HDS: implemented (effort saved: high) The HDS-operated API returns events and streams as canonical JSON validated against the data-type schemas — a commonly used electronic format. The app-portability web app (portability.hds.ngo) packages the full account into ZIP files the subject downloads in one self-service flow. For direct controller-to-controller transmission, the consent and capability-access flow mints a URL the receiving controller can read. Detail: Portability requires no operational lift on the data subject's side. The ZIP format matches the upstream pryv-account-backup CLI restore format, so the subject can re-hydrate on a self-hosted or partner-hosted node. HDS adds an `hds-manifest.json` (data-model version pin, app version, deploy URL, completion timestamp) for provenance. Evidence: doc:https://demo-portability.datasafe.dev, doc:https://portability.hds.ngo, doc:https://github.com/healthdatasafe/app-portability, internal:gdpr/procedures/data-subject-rights IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You export your data in canonical JSON or transmit it to another controller via the capability flow. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Supply the data you hold on request, and support a direct transmission where feasible. Portability out of the vault itself is between the individual and HDS. IMPLEMENTER [processor] coverage: documented applies_when: always Provide the controller with the data needed to satisfy portability. Templates to sign: dpa ## swiss-nlpd Art.31 — Justification for processing sensitive personal data Requirement: Processing of sensitive personal data without consent requires an overriding private or public interest, with enumerated grounds such as medical care, social assistance and statistics under conditions. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-31 PRYV PLATFORM: facilitated (mode: storage) Same approach as GDPR Art. 9: legal-ground determination is your programmatic decision; Pryv preserves the cited ground per access in `access.clientData.legal_ground` so the justification travels with the technical authorization and lives in the audit trail. The Swiss-specific enumeration (Art. 31 §2 list) drives the vocabulary your implementer uses for the `legal_ground` values. HDS: facilitated (effort saved: low) (mode: storage) The legal-ground determination is the controller's programmatic decision. HDS preserves the cited ground per access in client-data so the justification travels with the technical authorization and lives in the audit trail. Detail: The nLPD's enumerated grounds drive the vocabulary the controller uses for the recorded legal-ground values. HDS stores and audits the ground; it does not determine which ground applies. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [secondary-use] Determine the overriding interest or consent basis for what you hold, and record the cited ground in your own register. IMPLEMENTER [processor] coverage: documented applies_when: [secondary-use] Process sensitive data only on the ground the controller records. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.32 — Rectification, erasure and destruction of personal data Requirement: The controller must take appropriate measures to keep personal data accurate; the data subject may request rectification, erasure or destruction of inaccurate or no-longer-needed personal data. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-32 PRYV PLATFORM: implemented Rectification and erasure: same mapping as GDPR Art. 16 + 17. `events.update` for rectification (with version preservation); `system.users.delete` for erasure (with the same engine-dependent backup semantics noted under GDPR Art. 17). HDS: implemented (effort saved: high) HDS exposes event update as the rectification primitive with version preservation, and operates account deletion as the erasure path. The backup semantics of erasure depend on the configured storage engine, and retention automation is a known gap the controller covers by process. Detail: Rectification preserves prior versions for auditability; erasure removes the account, with engine-dependent backup behaviour the controller should account for. Automated time-based destruction is not implemented and must be operated as a controller process. Evidence: internal:gdpr/procedures/data-subject-rights IMPLEMENTER [data-subject] coverage: facilitated applies_when: NOT YET CLASSIFIED (always shown) You rectify your data through the API and may request erasure. IMPLEMENTER [controller] coverage: documented applies_when: [connects] Rectify, erase and destroy within the copy and the records you hold, and operate that retention yourself as no automation is built in. The vault's own contents are the individual's to correct or delete. IMPLEMENTER [processor] coverage: documented applies_when: [connects] Execute rectification and erasure on the controller's instruction. Templates to sign: dpa ## swiss-nlpd Art.34 — Disclosure of personal data abroad Requirement: Personal data may be disclosed abroad only where the receiving state guarantees adequate protection or, in defined cases, with appropriate safeguards such as standard contractual clauses or Federal Council approval. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-34 PRYV PLATFORM: configurable The `data-residency` primitive is the technical control here: bind each subject's data to a hosting whose jurisdiction matches your transfer regime. For CH data, route subjects to a CH hosting and Art. 34 is moot (no disclosure abroad). For legitimate transfers (e.g., CH → EU with adequacy + appropriate safeguards), the per-user `hosting` field exposes which jurisdiction the data sits in, recoverable for audit. Detail: Cross-account / CMC disclosures across hostings inherit the same control: the counterparty access's `apiEndpoint` reveals which hosting (= jurisdiction) the receiving deployment lives in; document the legal basis (adequacy decision, BCRs, etc.) on the originating access's `clientData.cross_border_basis`. **Residency guarantee level**: core-level, enforced by architecture (see `context/core-affinity-architecture.md`). Cores share no event / stream / audit data; the data plane is core-affine + the client ↔ core path is direct over TLS with no Pryv-shipped intermediary. A CH-assigned subject's data lives exclusively on the CH core. The CMC-counterparty pattern is the one runtime case where a cross-jurisdiction read can happen (a foreign counterparty's client connects to the CH `apiEndpoint`), and that's the moment the implementer records the Art.34 legal basis on the access. HDS: configurable (effort saved: high) Data residency is the technical control: HDS hosts CH-region data in Switzerland, so a vault registered in the CH region keeps the data in Switzerland and the cross-border question is moot. For legitimate transfers the per-user hosting field exposes which jurisdiction the data sits in, recoverable for audit. Detail: Cross-account disclosures inherit the same control: the counterparty access endpoint reveals the receiving jurisdiction, and the legal basis — adequacy, standard contractual clauses or another safeguard — is recorded on the originating access client-data. The CH region is operated in Switzerland; residency is enforced at the core level by architecture. Evidence: internal:gdpr/policies/international-transfers, internal:hipaa/registers/hosting-provider-attestations IMPLEMENTER [controller] coverage: documented applies_when: [transfer-ch-us, third-parties] You cannot choose a region per subject; the individual picks it when they register. Where data leaves Switzerland by your own hand, record the adequacy or safeguard basis. IMPLEMENTER [processor] coverage: documented applies_when: [transfer-ch-us, third-parties] Disclose abroad only on the controller's instruction and recorded basis. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.35 — Disclosure of personal data abroad — particular cases Requirement: Disclosure abroad without adequate protection requires one of the defined exceptions, such as the subject's consent, performance of a contract or an overriding interest. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-35 PRYV PLATFORM: facilitated (mode: storage) Exception-based transfers require recording the legal basis. Pryv pattern: the access authorising the disclosure carries the exception type in `clientData.transfer_exception` (e.g., `"art_35_consent"`, `"art_35_contract"`); the audit row at disclosure time anchors the exception to the specific event(s) transferred. HDS: facilitated (effort saved: low) (mode: storage) Exception-based transfers require recording the legal basis. HDS stores the exception type on the access authorising the disclosure, and the audit row at disclosure time anchors the exception to the specific events transferred. Detail: The exception vocabulary follows the nLPD enumeration; HDS preserves the cited exception and the disclosure event. Whether an exception applies is the controller's legal judgement. Evidence: internal:gdpr/policies/international-transfers IMPLEMENTER [controller] coverage: documented applies_when: [transfer-ch-us] Determine the applicable exception and record it against the disclosure you make, in your own transfer records. IMPLEMENTER [processor] coverage: documented applies_when: always Transfer under an exception only on the controller's recorded basis. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.2 — Material scope Requirement: The Act applies to the processing of personal data of natural persons by private persons and federal bodies; it does not apply to purely personal use, parliamentary proceedings, or pending judicial or administrative procedures. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-2 PRYV PLATFORM: facilitated (mode: awareness) Your Pryv deployment is fully in scope as automated processing of personal data. The "purely personal use" exception (§2 §1 lit a) doesn't reach a hosted Pryv deployment where you act as operator / controller for others. HDS: facilitated (effort saved: low) (mode: awareness) An HDS deployment is fully in scope as automated processing of personal data. The purely-personal-use exception does not reach a hosted deployment where the controller acts for others. HDS contributes awareness, not a scope-determining control. Detail: HDS makes no scope determination; the controller establishes whether and how the Act applies to its processing. The platform's audit and access records evidence that processing occurs. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: always; nature: orientation (not a duty) Determine whether and how the Act applies to your processing. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.3 — Territorial scope Requirement: The Act applies to facts that have an effect in Switzerland, even if initiated abroad. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-3 PRYV PLATFORM: facilitated (mode: infrastructure) Whether revFADP applies depends on whether processing affects CH data subjects, not on where infrastructure lives. Pryv's data-residency primitive lets you bind subjects to CH hostings explicitly when CH jurisdiction is the chosen regime, see Art. 34 for the cross-border transfer side. HDS: facilitated (effort saved: low) (mode: infrastructure) Applicability turns on whether processing affects data subjects in Switzerland, not on where infrastructure lives. HDS operates a CH region in Switzerland, and an individual who chooses it at registration keeps their vault under Swiss jurisdiction. Detail: The cross-border transfer side is handled under Art. 34. HDS supplies and operates the residency mechanism; the determination of territorial applicability to an organisation's own processing is that organisation's. Evidence: internal:hipaa/registers/hosting-provider-attestations Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: always; nature: orientation (not a duty) Work out whether the Act reaches your own processing, if you carry out any. You cannot bind an individual to a region: they choose it when they register their vault. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.16 — Disclosure of personal data abroad — principles (cross-link) Requirement: Personal data may be disclosed abroad only where adequate protection has been determined or appropriate safeguards are in place; Art. 34 sets out the operative framework. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-16 PRYV PLATFORM: facilitated (mode: awareness) Framing row pointing at Art. 34 for the operative Pryv mapping and at GDPR Chapter V (Art. 44-50) for the parallel EU regime. HDS: facilitated (effort saved: low) (mode: awareness) This is a framing row pointing at Art. 34 for the operative HDS mapping. HDS's contribution — data residency and recorded transfer basis — is described there. Detail: See Art. 34 for the data-residency control and the basis-recording pattern that satisfy the cross-border principle in practice. Evidence: internal:gdpr/policies/international-transfers, internal:hipaa/risk/cross-core-residency-data-flow IMPLEMENTER [controller] coverage: documented applies_when: [transfer-ch-us, third-parties] Apply the Art. 34 framework; this row is cross-reference only. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.30 — Justification of breaches of privacy Requirement: Processing that breaches privacy is unlawful unless justified by the subject's consent, an overriding private or public interest, or by law. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-30 PRYV PLATFORM: facilitated (mode: storage) Same pattern as GDPR Art. 6, justification basis is recorded on the access's `clientData.legal_basis` (Swiss-specific vocabulary drawn from Art. 30 §2 list). Determination of which basis applies is your editorial / legal judgement. HDS: facilitated (effort saved: low) (mode: storage) HDS records the justification basis on the access client-data, drawing on the nLPD's vocabulary, so the basis travels with the technical authorization and lives in the audit trail. Determining which basis applies is the controller's editorial and legal judgement. Detail: The pattern mirrors lawful-basis recording: the cited basis is stored per access and anchored in time by the audit log. HDS stores and audits it; it does not select it. Evidence: internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [connects] Determine the justification basis for your own processing and record it in your own register. IMPLEMENTER [processor] coverage: documented applies_when: [connects] Process only on the basis the controller records. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.4 — Federal Data Protection and Information Commissioner (FDPIC) Requirement: The Commissioner supervises application of data-protection law by federal bodies and private persons, advises them, investigates breaches and issues recommendations and orders. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-4 PRYV PLATFORM: out-of-scope The FDPIC is a regulator; no software role. When an FDPIC investigation involves a Pryv deployment, the audit log + access-version chain are the evidence layer the controller provides, but interaction with the FDPIC is the controller's legal / regulatory process. HDS: out-of-scope The Commissioner is a regulator; there is no software role. Where an investigation involves an HDS deployment, the audit log and access version chain are the evidence layer the controller can provide. Detail: Interaction with the Commissioner is the controller's legal and regulatory process. HDS supplies no control specific to this Article. IMPLEMENTER [controller] coverage: documented applies_when: always; nature: orientation (not a duty) Manage your interaction with the Commissioner; use platform records as evidence where needed. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.23 — Privacy by default Requirement: The controller must by default ensure processing is limited to the minimum required for the purpose, in particular through appropriate technical settings. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-23 PRYV PLATFORM: facilitated (mode: primitive) Pryv defaults lean privacy- protective by construction: smallest-permission default is "none"; system streams isolate privileged data; per-user storage isolates subjects. The operator's deployment-time choices (token-scope defaults, retention policy, MFA-on) determine whether the by-default posture is fully exercised. HDS: facilitated (effort saved: medium) (mode: primitive) The platform HDS operates leans privacy-protective by construction: the smallest-permission default is none, system streams isolate privileged data, and per-user storage isolates subjects. Whether the by-default posture is fully exercised depends on the controller's deployment-time choices. Detail: The smallest-permission default is none. The vault's own defaults are HDS's to set, with interactive session lifetime and per-grant token expiry under the account holder's control and approval, and multi-factor authentication available to them. An organisation sets the equivalent defaults in its own systems. HDS supplies the minimum-by-default primitives those settings exercise. Evidence: internal:hipaa/policies/minimum-necessary, internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Keep your own processing to the minimum: request the narrowest grant, retain the least, and enforce MFA on your own systems. The vault's defaults are HDS's. IMPLEMENTER [processor] coverage: documented applies_when: always Operate within the minimal defaults the controller sets. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.26 — Restriction of the right to information Requirement: The right to information under Art. 25 may be restricted, refused or deferred where a law so provides, where an overriding third-party interest requires it, or where the request is manifestly unfounded. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-26 PRYV PLATFORM: facilitated (mode: storage) When a controller invokes Art. 26 to restrict / refuse / defer a DSAR, the rationale is recorded as a `dsar/restricted` event on a designated stream with `clientData.art26_basis` capturing the §1 letter (a / b / c). Audit log anchors the decision in time. Whether a given restriction is justified is the controller's legal judgement. HDS: facilitated (effort saved: low) (mode: storage) When the controller invokes Art. 26 to restrict, refuse or defer an access request, HDS supports recording the rationale as an event on a designated stream with the cited statutory letter, time-anchored by the audit log. Whether the restriction is justified is the controller's legal judgement. Detail: The restriction record travels with the request artefacts so the decision is reconstructable later. HDS stores and audits the rationale; it makes no determination of justification. Evidence: internal:gdpr/procedures/data-subject-rights IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Determine whether a restriction applies and record the basis and rationale. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.33 — Cross-border international cooperation Requirement: The Federal Council may conclude international treaties on the cross-border exchange of personal data, including treaties on mutual data-protection cooperation. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-33 PRYV PLATFORM: out-of-scope Treaty-level activity. No software role; no implementer obligation arises from this Article alone. HDS: out-of-scope This is treaty-level activity with no software role. No implementer obligation arises from this Article alone, and HDS supplies no control specific to it. Detail: The Article addresses inter-state instruments rather than processing operations; HDS's residency and transfer controls under Art. 34 are the relevant operational layer. IMPLEMENTER [controller] coverage: out-of-scope applies_when: always; nature: orientation (not a duty); PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.9 — Processing by a processor Requirement: The controller may entrust processing to a processor only where the processor processes data solely as instructed, ensures equivalent data security, and obtains controller approval before engaging a sub-processor. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-9 PRYV PLATFORM: facilitated (mode: storage) Same pattern as GDPR Art. 28: when the Pryv operator is a processor distinct from the controller, the DPA + sub-processor list are the operator's contractual artefacts. Pryv's audit log enforces "only as instructed" demonstrability; the observability-provider primitive is the sole built-in subprocessor candidate (default disabled). HDS: facilitated (effort saved: medium) (mode: storage) This article governs an organisation's engagement of its own processors. HDS is not one of them for the vault: it is the controller there and does not act on another organisation's instructions. What it offers is a sub-processor register covering the providers it engages downstream, and an audit log that makes processing demonstrably attributable to the access that performed it. Detail: An organisation's engagement, approval and flow-down terms sit in its contracts with its own processors. HDS keeps the sub-processor register for the providers it engages, and uses the audit and access primitives to evidence what was done under which access. Evidence: internal:hipaa/registers/subprocessor-register, internal:hipaa/policies/access-control Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy, third-parties] If you engage processors of your own for the copy you hold, contract with them, give documented instructions and approve their sub-processors. This is not an agreement with HDS: HDS is the controller of the vault, not your processor. Templates to sign: dpa IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy, third-parties] Process only as instructed, ensure equivalent security and obtain approval before engaging sub-processors. Templates to sign: dpa, subprocessor IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.12 — Register of processing activities Requirement: Each controller and processor must maintain a register of processing activities, subject to an exception for smaller enterprises whose processing poses a low risk; content parallels GDPR Art. 30. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-12 PRYV PLATFORM: implemented Same primitive-set mapping as GDPR Art. 30: access + clientData + audit + CMC + data-residency form the technical register substrate. Swiss-specific note: the SME exception (Ordinance on Data Protection) drops register obligation for companies < 250 personnel processing low-risk data. The register substrate is available regardless; whether it's required is operator-side legal judgement. HDS: facilitated (effort saved: high) (mode: evidence) HDS supplies the technical register substrate: access, client-data, audit and data-residency records describe much of the processing. HDS also maintains its own register as controller, carrying eight live processing activities. What it does not do is generate or keep an implementer's register, which the implementer must author. Detail: The nLPD's small-enterprise exception does not reach large-scale processing of sensitive personal data, and hosting health records is exactly that, so an implementer handling health data should not expect the exemption to drop this obligation; whether it applies to its own processing at all remains its legal judgement. The substrate is available regardless, and the register document itself stays the controller's to author and maintain. Evidence: internal:gdpr/registers/records-of-processing PLANNED (doc, impact low): HDS's processor-side register is populated with its live processing activities. What remains is narrower: retention periods are not set for the recruitment, CRM and contact-mailbox rows, and the Art.30(2) half stays empty until the first partner DPA is executed, which the register states rather than filling with a fictional row. IMPLEMENTER [controller] coverage: documented applies_when: [stores-phi-copy] Author and maintain your register of processing activities, using platform records as input. IMPLEMENTER [processor] coverage: documented applies_when: [stores-phi-copy] Maintain your own register of the processing you perform for the controller. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.17 — Exceptions to the duty to inform Requirement: The information duty may be waived where the subject already has the information, the processing is provided for by law, the controller is bound by professional secrecy, or informing would be disproportionate. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-17 PRYV PLATFORM: out-of-scope Exception-applicability is the controller's legal judgement; no software role. Where the exception applies, the controller's reasoning is documentable in `account.clientData.art17_basis` for auditor questions. HDS: out-of-scope Exception applicability is the controller's legal judgement with no software role. Where an exception applies, HDS supports documenting the reasoning as client-data so it is available for auditor questions. Detail: HDS makes no exception determination. The controller's reasoning can be stored alongside the account or notice artefacts for traceability. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Determine whether an exception applies and document the reasoning. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.18 — Information when collecting personal data — specific cases Requirement: Beyond the Art. 19 baseline, the controller must provide additional information when transferring abroad, when processing involves automated decision-making, and in cases involving sensitive personal data. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-18 PRYV PLATFORM: facilitated (mode: storage) Additional disclosures are stored alongside the baseline notice in `access.clientData.privacy_notice` (or as additional `consent/notice` events for clarity). The cross-border transfer element ties to Art. 34; automated-decision element ties to Art. 21. HDS: facilitated (effort saved: low) (mode: storage) HDS stores the additional disclosures alongside the baseline notice as client-data or dedicated notice events. The cross-border element ties to Art. 34 and the automated-decision element to Art. 21; HDS preserves what was presented. Detail: The content of the additional disclosures is the controller's editorial responsibility. HDS makes the presented text recoverable per subject and per time as a durable artefact. Evidence: internal:hipaa/policies/notice-of-privacy-practices Evidence backing: every internal document cited above has completed approval. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Provide the additional information for transfers abroad, automated decisions and sensitive data, and record what was presented. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.11 — Codes of conduct Requirement: Professional, sector or trade associations may submit codes of conduct to the Commissioner, who takes a position on the code. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-11 PRYV PLATFORM: out-of-scope Sector-level instrument; see GDPR Art. 40 for parallel framing. Adherence is recorded as one of the Art. 8 "appropriate measures" indicators on the deployment. HDS: out-of-scope Codes of conduct are a sector-level instrument with no software role. Adherence to a code may be cited as one of the appropriate-measures indicators on a deployment, but HDS supplies no control specific to this Article. Detail: Drafting, submitting and adhering to a code is an association and controller matter outside the platform's scope. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Decide whether to adhere to an applicable code of conduct. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.14 — Representative in Switzerland Requirement: A controller established abroad whose processing concerns persons in Switzerland on a large scale, regularly and with high risk must designate a representative in Switzerland. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-14 PRYV PLATFORM: out-of-scope Representative designation is a contractual / regulatory registration step for non-Swiss controllers; no software role. HDS: out-of-scope Designating a Swiss representative is a contractual and regulatory registration step for non-Swiss controllers with no software role. HDS supplies no control specific to this requirement. Detail: Whether the threshold is met and who is designated are the controller's decisions outside the platform's scope. IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Determine whether you must designate a Swiss representative and do so if required. IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.15 — Duty of the processor to inform the controller Requirement: The processor must inform the controller of all data security breaches without delay and cooperate with the controller in fulfilling its obligations toward data subjects. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-15 PRYV PLATFORM: facilitated (mode: evidence) When Pryv operator acts as processor, the breach-notification channel to the controller is the operator's contractual commitment. Pryv's audit + observability + access primitives give the operator the scoping data needed for the notification; CMC's cross-platform messaging is a structured channel when both sides run Pryv. HDS: facilitated (effort saved: medium) (mode: evidence) This duty binds a processor toward its controller. HDS holds no such role in the vault: it acts on the individual's permissions rather than on an organisation's instructions, so the duty does not attach to it here. What HDS supplies is the audit and access primitives that give whoever does carry the duty the scoping data a notification needs. An organisation's own processors owe it this duty, and its contracts with them are where that is fixed. Detail: The notification channel and the assistance on subject requests are fixed in the contract between an organisation and its own processors. HDS supplies the scoping evidence from the audit and access-version data; the duties toward subjects remain the controller's. Evidence: internal:hipaa/procedures/security-incident-response, internal:gdpr/procedures/breach-notification-72h IMPLEMENTER [processor] coverage: documented applies_when: always Notify the controller of breaches without delay and assist with data-subject obligations. Templates to sign: dpa IMPLEMENTER [controller] coverage: documented applies_when: [processes-personal-data] Ensure the contracts with your own processors oblige them to notify breaches and assist you. Templates to sign: dpa IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA ## swiss-nlpd Art.29 — Information from official registers Requirement: Anyone may obtain information from official registers under the conditions set out in special legislation. Anchor: https://compliance.datasafe.dev/swiss-nlpd.html#req-art-29 PRYV PLATFORM: out-of-scope Public-register access is regulatory framing; no software role. HDS: out-of-scope Access to official public registers is a regulatory framing with no software role. HDS supplies no control specific to this Article. Detail: The Article concerns statutory public-register access rather than the controller's own processing operations. IMPLEMENTER [controller] coverage: out-of-scope applies_when: always; PLACES NO DUTY ON THIS PERSONA IMPLEMENTER [data-subject] coverage: out-of-scope applies_when: NOT YET CLASSIFIED (always shown); PLACES NO DUTY ON THIS PERSONA