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

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.

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

✓ backed by approved documentation

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.

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

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.

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

✓ backed by approved documentation

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

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

✓ backed by approved documentation

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.

• 🔒 hipaa/policies/notice-of-privacy-practices available on request
• 🔒 gdpr/policies/lawful-basis-and-consent available on request

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.

• 🔒 hipaa/procedures/security-incident-response available on request

✓ backed by approved documentation

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.

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

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.

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

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.

• 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
• 🔒 hipaa/procedures/security-incident-response available on request

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.

• 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

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.

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

✓ backed by approved documentation

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.

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

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.

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

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.

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

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.

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

✓ backed by approved documentation

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.

• 🔒 hipaa/registers/hosting-provider-attestations available on request

✓ backed by approved documentation

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.

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

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.

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

✓ backed by approved documentation

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.

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.

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

✓ backed by approved documentation

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.

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

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.

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.

• 🔒 hipaa/registers/subprocessor-register available on request
• 🔒 hipaa/policies/access-control available on request

✓ backed by approved documentation

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.

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

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.

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.

• 🔒 hipaa/policies/notice-of-privacy-practices available on request

✓ backed by approved documentation

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.

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.

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.

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

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.