General Data Protection Regulation GDPR

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 gdpr/policies/international-transfers available on request
• 🔒 hipaa/registers/hosting-provider-attestations available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 gdpr/policies/data-retention available on request
• 🔒 hipaa/policies/minimum-necessary available on request
• 🔒 hipaa/policies/integrity available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request
• 🔒 hipaa/policies/access-control available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 hipaa/policies/access-control available on request

✓ backed by approved documentation

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.

• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• doc: https://demo-portability.datasafe.dev
• doc: https://portability.hds.ngo
• doc: https://github.com/healthdatasafe/app-portability
• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• doc: https://demo-portability.datasafe.dev
• doc: https://portability.hds.ngo
• 🔒 hipaa/policies/integrity available on request
• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• doc: https://www.healthdatasafe.org/users/data-deletion
• doc: https://demo-portability.datasafe.dev
• doc: https://portability.hds.ngo
• 🔒 gdpr/procedures/data-subject-rights available on request
• 🔒 gdpr/policies/data-retention available on request
• 🔒 hipaa/procedures/data-backup-plan available on request

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.

• 🔒 hipaa/policies/access-control available on request
• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• doc: https://demo-portability.datasafe.dev
• doc: https://portability.hds.ngo
• doc: https://github.com/healthdatasafe/app-portability
• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• 🔒 hipaa/policies/access-control available on request
• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• 🔒 gdpr/procedures/data-subject-rights available on request

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.

• 🔒 hipaa/policies/access-control available on request
• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 gdpr/registers/records-of-processing available on request

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.

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

• 🔒 hipaa/policies/access-control available on request
• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 hipaa/policies/access-control available on request
• 🔒 gdpr/policies/data-retention available on request

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.

• 🔒 hipaa/registers/subprocessor-register available on request
• 🔒 hipaa/registers/hosting-provider-attestations available on request
• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 hipaa/policies/encryption available on request
• 🔒 hipaa/policies/transmission-security available on request
• 🔒 hipaa/policies/access-control available on request
• 🔒 hipaa/risk/at-rest-encryption available on request
• 🔒 hipaa/evidence/at-rest-encryption-verification available on request

✓ backed by approved documentation

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.

• 🔒 gdpr/procedures/breach-notification-72h available on request
• 🔒 hipaa/procedures/security-incident-response available on request

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.

• 🔒 gdpr/procedures/breach-notification-72h available on request
• 🔒 hipaa/procedures/security-incident-response available on request

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.

• 🔒 gdpr/procedures/dpia available on request

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.

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.

• 🔒 hipaa/registers/designated-roles available on request

✓ backed by approved documentation

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.

• 🔒 gdpr/procedures/dpia available on request

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.

• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 gdpr/registers/records-of-processing available on request

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.

• 🔒 gdpr/registers/records-of-processing available on request

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.

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.

• 🔒 gdpr/policies/international-transfers available on request
• 🔒 hipaa/registers/hosting-provider-attestations available on request
• 🔒 hipaa/risk/cross-core-residency-data-flow available on request

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.

• 🔒 gdpr/policies/international-transfers available on request
• 🔒 hipaa/registers/hosting-provider-attestations available on request

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.

• 🔒 gdpr/policies/international-transfers available on request
• 🔒 hipaa/registers/subprocessor-register available on request
• 🔒 hipaa/risk/cross-core-residency-data-flow available on request

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.

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.

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.

• 🔒 gdpr/policies/international-transfers available on request

Developing international-cooperation mechanisms is a regulator-level activity with no software contribution and no implementer obligation arising from this Article alone.