regulation · Switzerland (extraterritorial via Art. 3 for processing affecting CH) · SR 235.1 (revFADP / nLPD, in force 2023-09-01) CH
· layered on Pryv swiss-nlpd
Art.5 Definitions draft
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.
Pryv platform facilitated
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.
HDS facilitated CH
On top of Pryv's primitive model, HDS operates the platform on which the
controller designs the stream layout. The classification of a data
category as sensitive — including the nLPD's broader categories — is the
controller's editorial decision, which HDS carries into the access and
audit record.
detail
The recommended pattern dedicates separate stream subtrees per
sensitive-data category and grants accesses scoped to the smallest
necessary subtree, so the heightened-protection posture follows the
topology. HDS stores and enforces that layout; it does not assign the
sensitivity classification.
- 🔒 hipaa/policies/access-control available on request
Implementer
controller documented
Classify data categories — including the nLPD's broader sensitive
categories — and design stream topology and permission scopes
accordingly.
processor documented
📄 dpa
Process the categories the controller designates only as instructed.
data-subject out-of-scope
Art.6 Principles of processing draft
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.
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.
HDS implemented CH
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
Implementer
controller documented
Determine the lawful purpose, present it recognisably at collection,
and define a retention and destruction policy.
processor documented
📄 dpa
Process only within the controller's stated purpose and instructions.
data-subject facilitated
You exercise rectification through the platform; prior versions are
preserved.
Art.7 Data protection by design and by default draft
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.
Pryv platform facilitated
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 CH
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; the per-deployment default
configuration is the controller's.
detail
What stays on the controller is the deployment-time choice of token
scopes minted, retention selected and the notice shown at registration.
HDS supplies and operates the privacy-by-design substrate that those
choices configure.
- 🔒 hipaa/policies/access-control available on request
Implementer
controller documented
Configure privacy-protective defaults at deployment — minimal token
scopes, retention policy and registration notice.
processor documented
📄 dpa
Operate within the design and defaults the controller sets.
data-subject out-of-scope
Art.8 Data security draft
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.
Pryv platform facilitated
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 CH
HDS operates the technical security baseline: TLS in transit, stream-scoped
permissions, MFA, multi-core high availability and operated backup and
restore. At-rest encryption of customer event data is a known gap and is
flagged so the controller can weigh it in its security assessment.
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 encryption of
the event store is not implemented and must be treated as a residual risk.
- 🔒 hipaa/policies/transmission-security available on request
- 🔒 hipaa/policies/encryption available on request
- 🔒 hipaa/risk/at-rest-encryption-gap available on request
Implementer
controller documented
Assess whether the operated measures meet your security obligation,
accounting for the at-rest encryption gap, and add organisational
measures.
processor documented
📄 dpa
Ensure equivalent security for any processing you perform and report
measures to the controller.
data-subject out-of-scope
Art.19 Information duty when collecting personal data draft
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.
Pryv platform facilitated
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.
HDS facilitated CH
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
Implementer
controller documented
Author the information notice, present it at collection and record the
source where data is acquired indirectly.
data-subject out-of-scope
Art.21 Automated individual decisions draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Identify exclusively-automated decisions, inform the subject and offer
the opportunity to state a view.
data-subject facilitated
You may record your view on an automated decision as an event.
Art.22 Data protection impact assessment draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Determine when a DPIA is required, run it, and use the platform
artefacts as inputs.
processor documented
📄 dpa
Assist the controller's DPIA with information about your processing.
data-subject out-of-scope
Art.24 Notification of data security breaches draft
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.
Pryv platform facilitated
Same Pryv contribution as
GDPR Art. 33: audit data + access-version chain let you scope
the breach (which subjects, which streams, 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.
HDS facilitated CH
HDS operates the audit log and access version chain that let the
controller scope a breach — which subjects, which streams, by which
access. The nLPD's "as soon as possible" timeline is the controller's to
meet; HDS provides the underlying scoping evidence.
detail
As a processor, HDS notifies the controller of breaches it detects so the
controller can meet its Commissioner-notification duty. The subject
notification trigger is more conditional than under GDPR; the controller's
incident-response matrix should encode both regimes where it faces both.
At-rest encryption of the event store is not implemented, which affects
the safe-harbour assessment of a leaked artefact.
- 🔒 hipaa/procedures/security-incident-response available on request
- 🔒 gdpr/procedures/breach-notification-72h available on request
- 🔒 hipaa/risk/at-rest-encryption-gap available on request
Implementer
controller documented
Run the risk assessment, notify the Commissioner as soon as possible and
assess whether subject notification is required.
processor documented
📄 dpa
Notify the controller of breaches without undue delay and assist
scoping.
data-subject out-of-scope
Art.25 Right to information (data-subject access) draft
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.
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 CH
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
Implementer
data-subject facilitated
You access your own data directly through the standard API or a portal
built on it.
controller documented
Operate the request process, meet the response timeline and supply the
extended minimum-information set.
processor documented
📄 dpa
Make data available to the controller to satisfy access requests.
Art.28 Right to data portability draft
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.
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 CH
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
Implementer
data-subject facilitated
You export your data in canonical JSON or transmit it to another
controller via the capability flow.
controller documented
Support the portability request and any feasible direct transmission.
processor documented
📄 dpa
Provide the controller with the data needed to satisfy portability.
Art.31 Justification for processing sensitive personal data draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Determine the overriding interest or consent basis and record the cited
ground on each access.
processor documented
📄 dpa
Process sensitive data only on the ground the controller records.
data-subject out-of-scope
Art.32 Rectification, erasure and destruction of personal data draft
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.
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 CH
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
Implementer
data-subject facilitated
You rectify your data through the API and may request erasure.
controller documented
Run the rectification and erasure process and operate retention and
destruction as automation is not built in.
processor documented
📄 dpa
Execute rectification and erasure on the controller's instruction.
Art.34 Disclosure of personal data abroad draft
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.
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.
HDS configurable CH
Data residency is the technical control: HDS hosts CH-region data in
Switzerland, so binding a subject to the CH region keeps the data in
Switzerland and the cross-border question 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
Implementer
controller documented
Choose the residency region per subject, and where data leaves
Switzerland record the adequacy or safeguard basis.
processor documented
📄 dpa
Disclose abroad only on the controller's instruction and recorded basis.
data-subject out-of-scope
Art.35 Disclosure of personal data abroad — particular cases draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Determine the applicable exception and record it on the disclosing
access.
processor documented
📄 dpa
Transfer under an exception only on the controller's recorded basis.
data-subject out-of-scope
Art.2 Material scope draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Determine whether and how the Act applies to your processing.
data-subject out-of-scope
Art.3 Territorial scope draft
The Act applies to facts that have an effect in Switzerland, even if
initiated abroad.
Pryv platform facilitated
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 CH
Applicability turns on whether processing affects data subjects in
Switzerland, not on where infrastructure lives. HDS operates a CH region in
Switzerland to which subjects can be bound explicitly when CH jurisdiction
is the chosen regime.
detail
The cross-border transfer side is handled under Art. 34. HDS supplies the
residency mechanism; the determination of territorial applicability is the
controller's.
- 🔒 hipaa/registers/hosting-provider-attestations available on request
Implementer
controller documented
Determine territorial applicability and bind subjects to the CH region
where appropriate.
data-subject out-of-scope
Art.16 Disclosure of personal data abroad — principles (cross-link) draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Apply the Art. 34 framework; this row is cross-reference only.
data-subject out-of-scope
Art.30 Justification of breaches of privacy draft
Processing that breaches privacy is unlawful unless justified by the
subject's consent, an overriding private or public interest, or by law.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Determine the justification basis and record it on the relevant access.
processor documented
📄 dpa
Process only on the basis the controller records.
data-subject out-of-scope
Art.4 Federal Data Protection and Information Commissioner (FDPIC) draft
The Commissioner supervises application of data-protection law by federal
bodies and private persons, advises them, investigates breaches and issues
recommendations and orders.
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 CH
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 documented
Manage your interaction with the Commissioner; use platform records as
evidence where needed.
data-subject out-of-scope
Art.23 Privacy by default draft
The controller must by default ensure processing is limited to the minimum
required for the purpose, in particular through appropriate technical
settings.
Pryv platform facilitated
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 CH
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
Token-scope defaults, retention policy and MFA settings are the
controller's configuration. HDS supplies the minimum-by-default
primitives those settings exercise.
- 🔒 hipaa/policies/minimum-necessary available on request
- 🔒 hipaa/policies/access-control available on request
Implementer
controller documented
Configure minimal defaults — token scopes, retention and MFA — so
processing is limited to the minimum required.
processor documented
📄 dpa
Operate within the minimal defaults the controller sets.
data-subject out-of-scope
Art.26 Restriction of the right to information draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Determine whether a restriction applies and record the basis and
rationale.
data-subject out-of-scope
Art.33 Cross-border international cooperation draft
The Federal Council may conclude international treaties on the cross-border
exchange of personal data, including treaties on mutual data-protection
cooperation.
Pryv platform out-of-scope
Treaty-level activity. No software role; no implementer
obligation arises from this Article alone.
HDS out-of-scope CH
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 out-of-scope
data-subject out-of-scope
Art.9 Processing by a processor draft
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.
Pryv platform facilitated
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 CH
Where HDS acts as processor distinct from the controller, it offers a Data
Processing Agreement and maintains a sub-processor register. The audit log
makes processing demonstrably attributable to instructed accesses, so the
only-as-instructed duty rests on a record.
detail
Sub-processor engagement follows the DPA's approval and flow-down terms.
HDS keeps the sub-processor register and uses the audit and access
primitives to evidence instructed-only processing; the substantive
instructions are the controller's.
- 🔒 hipaa/registers/subprocessor-register available on request
- 🔒 hipaa/policies/access-control available on request
Implementer
controller documented
📄 dpa
Execute a DPA, give documented instructions and approve sub-processors.
processor documented
📄 dpa📄 subprocessor
Process only as instructed, ensure equivalent security and obtain
approval before engaging sub-processors.
data-subject out-of-scope
Art.12 Register of processing activities draft
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.
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 CH
HDS supplies the technical register substrate — access, client-data, audit
and data-residency records describe much of the processing. The register
as a maintained document is a known gap: HDS does not generate or keep the
controller's register, which the controller must author.
detail
The nLPD's small-enterprise exception drops the obligation for low-risk
processing under the prescribed threshold; whether it applies is the
controller's legal judgement. The substrate is available regardless, but
the register document itself is the controller's and processor's to
maintain.
- 🔒 gdpr/registers/records-of-processing available on request
Implementer
controller documented
Author and maintain your register of processing activities, using
platform records as input.
processor documented
📄 dpa
Maintain your own register of the processing you perform for the
controller.
data-subject out-of-scope
Art.17 Exceptions to the duty to inform draft
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.
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 CH
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 documented
Determine whether an exception applies and document the reasoning.
data-subject out-of-scope
Art.18 Information when collecting personal data — specific cases draft
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.
Pryv platform facilitated
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 CH
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
Implementer
controller documented
Provide the additional information for transfers abroad, automated
decisions and sensitive data, and record what was presented.
data-subject out-of-scope
Art.11 Codes of conduct draft
Professional, sector or trade associations may submit codes of conduct to
the Commissioner, who takes a position on the code.
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 CH
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 documented
Decide whether to adhere to an applicable code of conduct.
data-subject out-of-scope
Art.14 Representative in Switzerland draft
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.
Pryv platform out-of-scope
Representative designation is a contractual / regulatory
registration step for non-Swiss controllers; no software role.
HDS out-of-scope CH
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 documented
Determine whether you must designate a Swiss representative and do so if
required.
data-subject out-of-scope
Art.15 Duty of the processor to inform the controller draft
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.
Pryv platform facilitated
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 CH
Where HDS acts as processor, breach notification to the controller is its
contractual commitment under the DPA. HDS uses the audit and access
primitives to give the controller the scoping data needed for the
notification and to cooperate on data-subject rights.
detail
The notification channel and the assistance on subject requests are
DPA-defined. HDS supplies the scoping evidence and cooperates; the duties
toward subjects are ultimately the controller's.
- 🔒 hipaa/procedures/security-incident-response available on request
- 🔒 gdpr/procedures/breach-notification-72h available on request
Implementer
processor documented
📄 dpa
Notify the controller of breaches without delay and assist with
data-subject obligations.
controller documented
📄 dpa
Ensure your DPA obliges processors to notify breaches and assist.
data-subject out-of-scope
Art.29 Information from official registers draft
Anyone may obtain information from official registers under the conditions
set out in special legislation.
Pryv platform out-of-scope
Public-register access is regulatory framing; no software role.
HDS out-of-scope CH
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 out-of-scope
data-subject out-of-scope