regulation · EU + EEA (extraterritorial via Art. 3) · Regulation (EU) 2016/679 (consolidated) CHUS
· layered on Pryv gdpr
Art.1 Subject matter and objectives draft
Rules on the protection of natural persons regarding the processing of
their personal data, alongside rules ensuring its free movement.
Pryv platform facilitated
GDPR's purpose is to protect
natural persons in how their personal data is processed, while
keeping that data freely movable. Pryv is designed for exactly
that — your subjects own their data, technical controls enforce
the consent they granted, and the API is open so data can move
without lock-in. The per-article rows below describe how each
obligation maps to the primitives Pryv gives you.
HDS documented CHUS
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
Implementer
controller documented
Run your own data-protection programme over the HDS substrate; the
per-article rows show what HDS carries and what stays with you.
data-subject out-of-scope
Art.2 Material scope draft
Applies to processing of personal data by automated means, and to
non-automated processing of data forming part of a filing system.
Pryv platform facilitated
Your Pryv deployment is
fully inside Article 2's material scope. Every event you store
and every API call your apps make is automated processing
covered by GDPR. Pryv does not exempt you from any per-article
obligation — it gives you the technical primitives that make
those obligations addressable (see Art.5+). Branch 2 (non-
automated processing inside a "filing system" — structured
paper records) doesn't surface at the Pryv layer; your own
paper records, if any, are outside the software boundary.
HDS documented CHUS
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
Implementer
controller documented
Confirm your processing is in scope (it generally is) and manage any
out-of-band paper records separately.
data-subject out-of-scope
Art.3 Territorial scope draft
Applies to processing in the context of an EU establishment, or to
processing relating to data subjects in the Union.
Pryv platform facilitated
Whether GDPR applies
to your Pryv deployment depends on where you're established and
where your data subjects are — not on the software. Pryv is
self-hosted, so you control data residency directly: the multi-
hosting feature lets you choose which jurisdiction each core
runs in, and either let end-users pick their hosting at
registration or auto-route them by your policy. If any of your
subjects are in the EU/EEA, GDPR applies to your deployment in
full.
HDS facilitated CHUS
HDS offers data residency in Switzerland (Exoscale) and the US (AWS), so
a controller can pin each subject's data to a chosen jurisdiction. The
Swiss option keeps EU/EEA-subject data under an adequacy regime; the US
option is an international transfer (see Art.44-49). Whether GDPR applies
is a function of establishment and subject location, not of the platform.
detail
HDS routes each subject to the CH or US region according to the
controller's policy and exposes the chosen region per user, so the
controller can attest "your data is stored in <region>". Even with
CH-only residency, a non-EU establishment offering services to EU
subjects is still pulled into GDPR under Art.3(2) — a determination the
controller makes.
- 🔒 gdpr/policies/international-transfers available on request
- 🔒 hipaa/registers/hosting-provider-attestations available on request
Implementer
controller documented
Determine whether GDPR applies to your processing and select the CH or
US residency option accordingly.
data-subject out-of-scope
Art.4 Definitions draft
Defines key terms: personal data, processing, controller, processor,
consent, profiling, pseudonymisation and others.
Pryv platform facilitated
Article 4 defines GDPR
vocabulary. Pryv's primitives map cleanly to most of these
terms — easier for you to point auditors at concrete artefacts
rather than abstract concepts.
HDS documented CHUS
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. In
the usual SaaS arrangement HDS is the processor and the customer is the
controller; the role assignment is contractual.
detail
The controller/processor split is set in the data-processing agreement,
not by the software. HDS as processor acts on documented controller
instructions. The mapping of terms to primitives lets a controller point
an auditor at artefacts rather than abstractions.
- 🔒 gdpr/policies/lawful-basis-and-consent available on request
Implementer
controller documented
Assign the controller/processor roles in your DPA and apply the GDPR
definitions to your own processing description.
processor documented
📄 dpa
Where you process on behalf of another controller, document your
processor role and the instructions you act on.
Art.5 Principles relating to processing of personal data draft
Lawfulness, fairness, transparency; purpose limitation; data minimisation;
accuracy; storage limitation; integrity and confidentiality;
accountability.
Pryv platform implemented
Several Art.5 principles are technically enforced for you by Pryv
rather than left to policy: purpose limitation (per-stream
permissions), accountability (audit chain to the consent state),
accuracy (event versioning). Lawfulness, fairness and transparency
stay on your shoulders — Pryv stores the notice/consent text you
present but doesn't generate it for you.
HDS facilitated CHUS
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
Implementer
controller documented
Establish lawful basis, notices and a retention schedule; HDS does not
set these for you. Automated retention deletion is your job to build.
data-subject out-of-scope
Art.6 Lawfulness of processing draft
Processing is lawful only if at least one of six bases applies; further
processing for a new purpose needs a compatibility test or a fresh basis.
Pryv platform facilitated
You decide which Art.6 basis
you're relying on for each processing activity. Pryv doesn't
impose or check the basis. You can record your chosen basis in
`access.clientData.lawful_basis` so it travels alongside the
technical authorization and lives in the audit trail — handy
when an auditor asks "under what basis was this access made?".
For Art.6(4) further processing (purpose pivot), Pryv exposes
four composable patterns + a clear decision rule for when the
purpose pivot demands fresh consent vs. an in-place update —
see detail.
HDS facilitated CHUS
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
Implementer
controller documented
Determine and document the lawful basis for each processing activity
and record it on the relevant accesses.
data-subject out-of-scope
Art.7 Conditions for consent draft
Where processing relies on consent, the controller must demonstrate it;
the request must be intelligible and the consent withdrawable.
Pryv platform implemented
The access Pryv mints when your user grants permission IS your
durable consent record — versioned permissions + clientData
together prove what was authorised, with what text, at what time.
Withdrawal is a single API call. For cross-account sharing, the
`consent/*` events carry the negotiation state transitions. Both
records are immutable per their primitive's semantics.
HDS facilitated CHUS
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
Implementer
controller documented
Write the consent UX and notice text; HDS preserves and versions the
record but does not author the request.
data-subject facilitated
Grant and withdraw consent through the access primitive at any time.
Art.9 Processing of special categories of personal data draft
Processing of special-category data (incl. health, genetic and biometric
data) is prohibited unless one of the Art.9(2) conditions applies.
Pryv platform facilitated
Pryv is content-agnostic at the platform layer — no
`sensitivity:` flag on event-type schemas, no server-side hook
that refuses writes to "health" streams without a recorded
Art.9(2) basis. **Classification is voluntarily missing at the
platform.** But for **vertically-integrated operators** (you
run the core AND ship the clients AND design the stream tree
AND curate the event-type catalogue — typical for
health deployments), Pryv exposes enough composable primitives
that you build a strong Art.9 enforcement layer without
platform-imposed assumptions. The Art.9(2) condition relied on
lives in `access.clientData.special_category_basis` next to
the technical grant. Full operator-toolkit treatment +
two-deployment-topologies framing in
`context/special-categories-operator-facilitated.md`.
HDS facilitated CHUS
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
Implementer
controller documented
Determine the Art.9(2) condition for each special-category processing
activity, design your streams accordingly, and record the basis.
data-subject out-of-scope
Art.8 Conditions applicable to child's consent in relation to information society services draft
Where consent grounds a service offered directly to a child, processing is
lawful only at/above the applicable age; below it, a parental holder must
consent.
Pryv platform facilitated
Pryv neither knows nor validates a subject's age — age +
parental-authority verification happens at your app's
registration / consent UX. The platform is age-blind by
design (verified: default `custom.systemStreams.account`
ships only `email`; no `birthDate` / `dateOfBirth` /
`minor` field in the catalogue). Once verified, the
artefacts you keep travel alongside the access via the
`clientData` convention family (see
`context/client-data-conventions.md`).
HDS facilitated CHUS
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
Implementer
controller documented
Verify age and parental authority in your UX and record the artefacts;
HDS stores them but performs no age checks.
data-subject out-of-scope
Art.10 Processing of personal data relating to criminal convictions and offences draft
Processing of criminal-conviction/offence data is allowed only under
official authority or where authorised by law with appropriate safeguards.
Pryv platform facilitated
Same pattern as Art. 9
special-category data: dedicate a `criminal-records/*` stream
subtree, scope every access tightly, record the Art. 10 legal-
basis-by-law citation in `access.clientData.art10_basis`. Pryv
has no role in deciding whether a given processing instance
falls under "official authority" — that's your legal judgement.
HDS facilitated CHUS
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
Implementer
controller documented
Confirm your legal authority to process such data and record the basis;
isolate the data in a dedicated, tightly scoped subtree.
data-subject out-of-scope
Art.12 Transparent information, communication and modalities draft
The controller must provide concise, transparent, intelligible information
and respond to data-subject requests within one month.
Pryv platform facilitated
Pryv preserves whatever
notice / consent text you presented to the subject — immutably,
versioned, retrievable later. The response operations
(Art.15-22) execute in sub-second; the 1-month rule is your
process target, not a software limit.
HDS facilitated CHUS
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
Implementer
controller documented
Write concise, intelligible notices and run a request-handling process
that meets the one-month deadline.
data-subject facilitated
Receive the preserved notice/consent text and exercise your rights
through the platform.
Art.13 Information to be provided where data are collected from the data subject draft
Controller identity, purposes, legal basis, recipients, retention and
rights must be provided at the time of collection.
Pryv platform facilitated
The information items split across two operator-controlled
surfaces:
- **Deployment-wide** (controller identity, DPO contact,
Terms of Service): the `serviceInfo` fields `home`,
`support`, `terms` — propagated to every client app via
`GET /service/info`; `app-web-auth3` renders them in its
consent UI by default. Full convention treatment in
`context/service-info-conventions.md`.
- **Per-access** (purposes, lawful basis, recipients,
retention, the specific rights notice): `access.clientData`
per the convention family in
`context/client-data-conventions.md` —
`lawful_basis`, `purpose`, `transfer_basis`, `retention`,
`consent`, `consent_event_id`, etc. (or a
`consent/request-cmc` event when using CMC). Pryv preserves
them immutably with version chain (`?includeHistory=true`);
your app surfaces them at the right moment.
HDS facilitated CHUS
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
Implementer
controller documented
Author and present the Art.13 disclosures at collection time; record
them on the service-info and access surfaces.
data-subject out-of-scope
Art.14 Information to be provided where data have not been obtained from the data subject draft
The same disclosures as Art.13 must be provided within a reasonable period
when data are obtained indirectly.
Pryv platform facilitated
When you ingest data into
Pryv from third parties (not directly from the subject), you
still owe the same disclosures as Art.13. Pryv lets you record
the disclosure artefact alongside the data, same as direct
collection (`access.clientData` or a `consent/*` event), and
the audit log proves when disclosure happened — useful when
the 1-month / first-contact deadlines come into question.
HDS facilitated CHUS
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
Implementer
controller documented
Record the data source and present the Art.14 disclosures within the
required period.
data-subject out-of-scope
Art.15 Right of access by the data subject draft
Right to obtain confirmation, access and a copy of personal data plus
supplementary information.
Pryv platform implemented
Your subject, holding a personal token, reads everything via the
standard Pryv API — events, streams, accesses (with full history),
audit records. The supplementary information (purposes, recipients)
is in `access.clientData` when you recorded it there. For
ready-made bundling, the `pryv-account-backup` npm tool walks the
subject's API endpoints and produces a downloadable folder —
operator-independent (the subject runs it with their own
credentials).
HDS implemented CHUS
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 is in the access clientData when the
controller 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
Implementer
controller documented
Run the request-intake process and, if desired, a subject portal; the
read mechanics are provided.
data-subject facilitated
Read or export your full data set directly via the API or the backup
tool.
Art.16 Right to rectification draft
Right to have inaccurate personal data rectified without undue delay.
Pryv platform implemented
`events.update` rectifies an event; event versioning preserves the
prior (inaccurate) value for traceability — addressing the
Art.5(1)(d) accuracy principle without losing the audit trail.
HDS implemented CHUS
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
Implementer
controller documented
Detect inaccuracy and trigger the rectification; the update and
versioning mechanics are provided.
data-subject facilitated
Request rectification, which is applied while preserving the prior
value for traceability.
Art.17 Right to erasure ("right to be forgotten") draft
Right to obtain erasure without undue delay where one of the enumerated
conditions applies.
Pryv platform configurable
Per-user erasure is a single API call (`system.users.delete`).
Whether erasure extends to your backups depends on the storage
engine you chose — SQLite per-user folders are deletable from
filesystem backups; PostgreSQL requires a backup-rotation
policy to complete erasure.
HDS configurable CHUS
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
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
Implementer
controller documented
Decide when an erasure obligation is triggered and invoke deletion;
define your own retention schedule, since automation is not provided.
data-subject facilitated
Request erasure of your account, applied across live data and audit
rows.
Art.18 Right to restriction of processing draft
Right to obtain restriction — data stored but not processed — in defined
circumstances.
Pryv platform configurable
Restriction is achieved by mutating the access — scope-down via
`accesses.update` (narrower permissions) or full revoke via
`accesses.delete`. Versioning preserves the pre-restriction state
so the change is auditable. No dedicated "restriction flag" — the
access mutation IS the restriction primitive.
HDS configurable CHUS
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
The controller lowers the relevant access's permissions to none on the
affected streams (or deletes the access) and may record the restriction
reason on the access clientData for the Art.30 register.
- 🔒 hipaa/policies/access-control available on request
- 🔒 gdpr/procedures/data-subject-rights available on request
Implementer
controller documented
Apply restriction by scoping or revoking the relevant accesses and
record the reason.
data-subject facilitated
Request restriction, applied as an access scope-down that halts
processing while preserving the data.
Art.20 Right to data portability draft
Right to receive personal data in a structured, commonly used,
machine-readable format and to transmit it to another controller.
Pryv platform implemented
`events.get` + `streams.get` return canonical JSON validated against
the data-types schemas — structured, commonly used, machine-readable.
Attachments downloadable. No proprietary lock-in: another Pryv
operator can import the data into a new account via standard
write APIs.
HDS implemented CHUS
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
Implementer
controller documented
Optionally wrap the export in a download UI; ensure schema alignment
for any direct controller-to-controller transmission.
data-subject facilitated
Export your data in portable JSON and have it transmitted to another
controller.
Art.21 Right to object draft
Right to object to processing based on legitimate or public interest;
absolute right to object to direct marketing.
Pryv platform facilitated
Pryv doesn't do profiling or marketing itself, but if your
app does either using Pryv-stored data, your subjects have
the right to object. **The mechanism is the same as Art.7(3)
withdrawal (Q19)** — `DELETE /accesses/:id` or
`accesses.update` to narrow permissions; Pryv's primitives
are basis-agnostic. The legal distinction between Art.21
objection (legitimate-interests / public-interest basis) and
Art.7(3) withdrawal (consent basis) is semantic, not
technical. Record the objection on the access's `clientData`
per the consolidated convention catalogue at
`context/client-data-conventions.md`.
HDS facilitated CHUS
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 controller records the objection and narrows or
revokes the marketing access so subsequent runs find no scope. For
legitimate-interest objections the controller also runs a
compelling-grounds review and records the outcome on the access; all of
it is versioned and auditable.
- 🔒 hipaa/policies/access-control available on request
- 🔒 gdpr/procedures/data-subject-rights available on request
Implementer
controller documented
Run the compelling-grounds assessment where applicable and apply the
objection by revoking or narrowing the relevant access.
data-subject facilitated
Object to processing; the objection is applied through the access
primitive and recorded.
Art.19 Notification obligation regarding rectification / erasure / restriction draft
The controller must communicate any rectification, erasure or restriction
to each recipient, unless impossible or disproportionate.
Pryv platform facilitated
The recipients are derivable
from Pryv data — the accesses the controller has minted to
third parties. When you exercise an Art. 16-18 action that
affects events held by those recipients, iterate the active
accesses and notify each holder out-of-band. For CMC-paired
counterparties, the `consent/revoke-cmc` or a custom
`notification/rectification` event provides a structured
notification channel.
HDS facilitated CHUS
The recipients are derivable from HDS data — the accesses the controller
minted to third parties. When an Art.16-18 action affects data held by
those recipients, the controller iterates the active accesses and
notifies each holder; CMC-paired counterparties have a structured
notification channel.
detail
The set of recipients to notify is reconstructable from the active
accesses; the out-of-band notification to each, and the
impossibility/disproportionality judgement, are the controller's.
- 🔒 gdpr/procedures/data-subject-rights available on request
Implementer
controller documented
Identify the recipients from the active accesses and notify each of the
rectification, erasure or restriction.
data-subject out-of-scope
Art.22 Automated individual decision-making, including profiling draft
Right not to be subject to a decision based solely on automated processing
producing legal or similarly significant effects, subject to exceptions.
Pryv platform facilitated
Pryv doesn't run automated
decisions — that's your application logic. What Pryv contributes
when Art.22 applies: (1) the audit log proves which inputs were
read for the decision; (2) the decision output can be written
as a Pryv event with the input reference + the decision logic
version captured in `clientData`, making "human intervention"
requests tractable (the subject can locate the specific decision
record); (3) the consent basis for §2(c) lives on the access's
clientData like every other consent record.
HDS facilitated CHUS
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 controller mints a dedicated access for the decision app, writes the
decision output with an input-audit reference and logic version, and uses
that trail to satisfy human-intervention requests. HDS supplies the
evidentiary substrate, not the decision.
- 🔒 gdpr/procedures/data-subject-rights available on request
Implementer
controller documented
Implement the safeguards (basis, human intervention) and record the
decision trail; the evidentiary primitives are provided.
data-subject out-of-scope
Art.24 Responsibility of the controller draft
The controller must implement and be able to demonstrate appropriate
technical and organisational measures, proportionate to the risk.
Pryv platform facilitated
Art. 24 is the umbrella
controller-accountability obligation that ties every other
Chapter-IV row together. Pryv contributes the technical-
measures substrate (this matrix enumerates it explicitly) +
the technical-measures demonstrability (audit log + access
version chain are the evidence layer). The organisational-
measures programme is yours.
HDS facilitated CHUS
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 as processor supplies access control, transport encryption,
monitoring and the evidence layer, and offers a DPA documenting its own
measures. The controller assembles these 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
Implementer
controller documented
Build and maintain your accountability programme, citing HDS technical
measures and your own organisational controls.
processor documented
📄 dpa
Where you act as a processor, evidence your own measures and operate on
documented controller instructions.
Art.26 Joint controllers draft
Where two or more controllers jointly determine purposes and means, they
must allocate their responsibilities in a transparent arrangement.
Pryv platform facilitated
**CMC is NOT a joint-controller pattern by default.** Pryv's
CMC primitive requires **subject validation** — User A's
`consent/accept-cmc` event is what authorises any cross-account
data flow to User B's operator. Each operator remains the
**sole controller** for their respective user's data; the
lawful basis for B's processing of A's data is A's CMC
consent record (Art.6(1)(a)), not a controller-to-controller
agreement. This is controller-to-controller transmission
*via subject consent* (Art.20(2) lineage), not Art.26 joint
controllership. Real Art.26 fires only if Operator-X +
Operator-Y separately decide to jointly process a category
of subjects' data — outside the CMC primitive.
HDS facilitated CHUS
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
Implementer
controller documented
If you are a joint controller, conclude the Art.26 arrangement and make
its essence available to subjects.
data-subject out-of-scope
Art.27 Representative of controllers / processors not established in the Union draft
A controller or processor not established in the Union must, where Art.3(2)
applies, designate an EU representative in writing, subject to exemptions.
Pryv platform out-of-scope
Representative designation is a contractual + regulatory
registration step. No software role.
HDS out-of-scope CHUS
Designating an EU representative is a contractual and regulatory
registration step with no software role. Where HDS itself processes for
EU subjects from a non-EU establishment, HDS makes its own designation;
the controller makes its own.
Implementer
controller documented
If Art.3(2) applies to you and no exemption holds, designate an EU
representative in writing.
data-subject out-of-scope
Art.29 Processing under the authority of the controller or processor draft
A processor and anyone acting under its or the controller's authority must
process personal data only on the controller's instructions.
Pryv platform facilitated
"Only on instructions" is
enforced operationally through the access primitive — workforce
/ contractor / app accesses are scoped to specific streams +
levels per the controller's instructions, and the audit log
proves what was actually done. Violations show as out-of-scope
access attempts or unauthorized method calls in the audit data.
HDS facilitated CHUS
"Only on instructions" is enforced operationally through the access
primitive: workforce, contractor and app accesses are scoped to specific
streams and levels per the controller's instructions, and the audit log
proves what was actually done. HDS as processor binds its own staff to
the same instruction-only discipline.
detail
Out-of-scope access attempts and unauthorised method calls surface in the
audit data, making instruction violations detectable. The substantive
instructions themselves come from the controller's DPA.
- 🔒 hipaa/policies/access-control available on request
- 🔒 gdpr/registers/records-of-processing available on request
Implementer
controller documented
Express your processing instructions as scoped accesses and review the
audit log for deviations.
processor documented
📄 dpa
Process only on documented controller instructions and keep your staff
within their scoped accesses.
Art.25 Data protection by design and by default draft
The controller must integrate data-protection principles into the design
and ensure privacy-protective default settings.
Pryv platform facilitated
Pryv's whole
architecture leans privacy-by-design — per-user storage
isolation, stream-scoped permissions, separate personal/app/
shared access types, privileged data on system streams. Your
defaults (token scopes, audit-on, retention) are the part still
in your hands.
HDS facilitated CHUS
The HDS architecture is privacy-by-design by founding pattern: per-user
storage isolation, default-deny stream-scoped permissions, separate
personal/app/shared access types, privileged data on system streams, and
audit-on by default. The controller's own defaults — token scopes,
retention period, opt-in UX — remain in its hands.
detail
Default-deny permissions, audit-by-construction, enforced transport
encryption and per-user residency pinning ship as platform defaults. The
controller still decides whether app tokens are minted with minimal
scope, whether notices default on, and how short the retention period is.
- 🔒 hipaa/policies/access-control available on request
- 🔒 gdpr/policies/data-retention available on request
Implementer
controller documented
Configure your defaults — minimal token scopes, opt-in notices, short
retention — on top of the platform's privacy-protective baseline.
data-subject out-of-scope
Art.28 Processor draft
Processing on behalf of a controller must be governed by a contract setting
out subject matter, duration, nature, purpose, data types and the parties'
obligations.
Pryv platform facilitated
When the Pryv operator and
the controller are distinct legal entities (typical SaaS
arrangement), the operator is the Art.28 processor. Pryv-the-
software provides the technical substrate the §1 "sufficient
guarantees" evaluation rests on (this matrix enumerates it);
the data-processing-agreement (DPA) under §3 is the operator's
contract. Audit log + access primitives carry "documented
controller instructions" (§3(a)) and the records that
demonstrate compliance (§3(h)).
HDS facilitated CHUS
In the usual arrangement HDS is the Art.28 processor and offers a
data-processing agreement covering the §3 terms and a documented
subprocessor posture. HDS ships zero mandatory subprocessors; every
external integration (SMTP, SMS, observability) is opt-in and inventoried
with its data-flow. The substantive §1 "sufficient guarantees"
evaluation is the controller's.
detail
HDS maintains a subprocessor register and hosting-provider attestations
and routes deletion/return of data at end of provision via account
deletion and backup tooling. The audit log and access primitives carry
the documented controller instructions and the demonstrability evidence.
A DPA template is offered.
- 🔒 hipaa/registers/subprocessor-register available on request
- 🔒 hipaa/registers/hosting-provider-attestations available on request
- 🔒 gdpr/registers/records-of-processing available on request
Implementer
controller documented
📄 dpa
Evaluate the processor's guarantees and conclude an Art.28 DPA before
processing begins.
processor documented
📄 dpa📄 subprocessor
Sign the DPA, maintain your subprocessor inventory and bind any
subprocessor on equivalent terms.
Art.30 Records of processing activities draft
Each controller and processor must maintain a record of its processing
activities (purposes, categories, recipients, transfers, retention,
security).
Pryv platform implemented
The combination of access + clientData + audit + (cross-account)
CMC + data-residency IS your Article 30 register: who, what, why,
when, recipients, transfers, retention — all derivable per-subject
and per-time-window from primitives Pryv records continuously.
HDS facilitated CHUS
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 processor-side record.
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
Implementer
controller documented
Maintain your Art.30 register, drawing the technical fields from the
platform's derivable inputs.
processor documented
📄 dpa
Keep your own processor-side record of the processing you perform for
each controller.
Art.32 Security of processing draft
The controller and processor must implement appropriate technical and
organisational security measures: pseudonymisation, encryption, ongoing
CIA, restoration and regular testing.
Pryv platform facilitated
Multi-aspect article —
Pryv implements several aspects for you (access control,
encryption-in-transit, restoration) and provides configurable
controls for others (encryption-at-rest, pseudonymisation, data
residency). Organizational measures (regular testing, incident
response procedures) stay in your court.
HDS facilitated CHUS
HDS implements transport encryption (TLS), technical access control and
per-user restore, and operates monitoring and alerting as operator.
Encryption at rest is a known gap at the application layer — it relies on
operator/infrastructure controls rather than a platform primitive.
Pseudonymisation and data residency are 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. At-rest encryption of event content is not provided
by the platform and is the standing gap noted in this matrix. 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-gap available on request
Implementer
controller documented
Assess the residual at-rest-encryption risk, run regular security
testing and document your incident procedures.
processor documented
📄 dpa
Evidence your own security measures and the at-rest controls applied at
the infrastructure layer.
Art.33 Notification of personal data breach to the supervisory authority draft
The controller must notify the supervisory authority within 72 hours of
becoming aware of a breach, unless it is unlikely to pose a risk.
Pryv platform facilitated
Pryv's audit log helps you
determine the scope of a breach (which data, which users, by
which access). Encryption-at-rest may scope the "unsecured
personal data" definition relevant to the notification decision.
The 72-hour process itself is yours to run.
HDS facilitated CHUS
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. The notification itself, and
the risk-likelihood judgement, are the controller's. At-rest encryption,
a known gap, would otherwise narrow the "unsecured data" definition.
detail
Audit queries over the suspected window list the accesses that touched
the data and the streams read; the access version chain shows whether
processing was within scope. HDS runs detection and an 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
Implementer
controller documented
Run the 72-hour notification process and make the risk determination;
the scoping substrate is provided.
processor documented
📄 dpa
Notify the controller without undue delay on becoming aware of a
breach.
Art.34 Communication of a personal data breach to the data subject draft
Where a breach is likely to result in high risk, the controller must
communicate it to affected data subjects without undue delay.
Pryv platform facilitated
Two-surface split. **Identification** is filled by the audit
log + the Q17 BREACH-SCOPE-TOOL backlog (per-subject roster
derivable from the breached access's read/write history);
**delivery** is voluntarily missing + operator-owned (Pryv's
mail surface is transactional per-recipient, not bulk-send;
operators compose with their existing CRM / SMS / push
pipeline). The audit-trace bridge that lands per-recipient
send-receipts inside Pryv's event chain (satisfying
§164.414-equivalent burden-of-proof) uses an operator-
authored `compliance/breach-notification/sent-cmc` event
pattern. Full treatment in
`context/breach-notification-delivery-operator-owned.md`.
Encryption-at-rest may scope the high-risk determination
(Art.34 §3(a) exemption).
HDS facilitated CHUS
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
encryption (a known gap) would otherwise scope the high-risk exemption.
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
Implementer
controller documented
Derive the affected-subject roster, render and deliver the
communication, and assess the high-risk and exemption questions.
data-subject out-of-scope
Art.35 Data protection impact assessment draft
Where processing is likely to result in a high risk, the controller must
carry out a data-protection impact assessment before processing.
Pryv platform facilitated
The DPIA is a written
assessment artefact — Pryv has no role in producing it. What
Pryv supplies as inputs: data-residency primitive lets you
state where each subject's data lives; audit + access-version
primitives describe the processing-flow technical layer
concretely; system-streams isolation gives a defensible "scope
of sensitive data" boundary; this matrix itself enumerates the
technical-organisational-measures (Art.35 §7(d)) for the
deployment.
HDS facilitated CHUS
The DPIA is a written assessment the controller produces; HDS supplies
inputs — data-residency facts, audit/access descriptions of the
processing flow, system-stream isolation as the sensitive-data boundary,
and this matrix as the technical-measures inventory. A formal DPIA
process is a known gap that the controller must run itself.
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
Implementer
controller documented
Run the DPIA where required, using the platform's technical inputs and
this matrix's measures inventory.
data-subject out-of-scope
Art.36 Prior consultation draft
The controller must consult the supervisory authority before processing
where a DPIA shows a high residual risk absent mitigation.
Pryv platform out-of-scope
Prior consultation is the controller's procedural interaction
with a supervisory authority. No software role; the DPIA
artefact under Art. 35 carries the technical evidence the
authority may request — Pryv contributes inputs there but not
to the consultation itself.
HDS out-of-scope CHUS
Prior consultation is the controller's procedural interaction with a
supervisory authority and has no software role. HDS contributes the
technical evidence the authority may request via the DPIA inputs noted at
Art.35, but not the consultation itself.
Implementer
controller documented
Consult the supervisory authority where your DPIA indicates an
unmitigated high risk.
data-subject out-of-scope
Art.37 Designation of the data protection officer draft
The controller and processor must designate a DPO in the cases listed,
including large-scale processing of special-category data.
Pryv platform out-of-scope
DPO designation is an HR / organizational decision. No software
role. Where the deployment processes Art. 9 special-category or
Art. 10 criminal data on a large scale (likely for healthcare
Pryv deployments), the Art. 37(1)(c) trigger applies and a DPO
designation is required.
HDS out-of-scope CHUS
DPO designation is an organisational decision with no software role.
Healthcare deployments processing special-category data at scale will
commonly trigger the Art.37(1)(c) requirement; HDS makes its own
processor-side designation and the controller makes its own.
Implementer
controller documented
Determine whether a DPO is required for your processing and designate
one where it is.
processor documented
📄 dpa
Designate your own DPO where the Art.37 triggers apply to your
processing.
Art.38 Position of the data protection officer draft
The DPO must be involved properly and timely, resourced, independent, and
reachable by data subjects.
Pryv platform facilitated
DPO independence + reporting structure (§1-§3) is an
organizational arrangement — no software role. **§4 DPO
contact-point for data subjects IS facilitated** by the
existing `serviceInfo.support` URL (returned by
`GET /service/info` on every core). Operators publish DPO
contact details on the page that `support` points at — the
same surface that `app-web-auth3` already renders in its
consent UI. Zero extra platform code required. Full
convention treatment in
`context/service-info-conventions.md`.
HDS facilitated CHUS
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
Implementer
controller documented
Establish the DPO's independence and reporting line and publish the
DPO contact point.
data-subject out-of-scope
Art.39 Tasks of the data protection officer draft
The DPO must, at minimum, inform and advise, monitor compliance, advise on
the DPIA, and cooperate with and be the contact point for the supervisory
authority.
Pryv platform facilitated
DPO duties are organizational. Pryv contributes the data
sources the DPO uses for "monitoring compliance" — the
audit log, observability metrics, this matrix's evidence
trail. The DPO contact-point obligation per Art.38(4) is
covered separately via the `serviceInfo.support` URL
convention (see `context/service-info-conventions.md`).
Pryv equips the DPO; it doesn't replace them.
HDS facilitated CHUS
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
Implementer
controller documented
Resource your DPO to perform these tasks using the platform's audit and
monitoring data and this matrix.
data-subject out-of-scope
Art.40 Codes of conduct draft
Authorities and bodies are to encourage codes of conduct that help apply
the Regulation properly.
Pryv platform facilitated
Codes of conduct are sector-
level instruments (drafted by associations of controllers /
processors, approved by competent supervisory authority). No
software role at the code-drafting layer. When a code applies
to your sector, adherence is recorded as one of the Art. 24 /
Art. 32 "appropriate measures"; the audit log + this matrix
demonstrate the technical-control side of code adherence.
HDS facilitated CHUS
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
Implementer
controller documented
Adhere to any applicable sector code and cite the platform's technical
controls as part of that adherence.
data-subject out-of-scope
Art.42 Certification draft
Authorities and bodies are to encourage data-protection certification
mechanisms, seals and marks.
Pryv platform facilitated
Certification (e.g.,
EuroPrivacy seal, GDPR-certified processor schemes) is sector-
and jurisdiction-specific. Pryv operators pursuing certification
consume this matrix as the technical-control inventory. ISO
27701 + (where applicable) HDS are adjacent certifications
already represented in this matrix.
HDS facilitated CHUS
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
Implementer
controller documented
Pursue any applicable certification using this matrix as your
technical-control inventory.
data-subject out-of-scope
Art.82 Right to compensation and liability draft
Anyone suffering material or non-material damage from an infringement is
entitled to compensation from the controller or processor.
Pryv platform facilitated
Liability + compensation are
legal proceedings. Pryv contributes defense evidence: the audit
log + access-version chain support the controller / processor
in demonstrating compliance with the relevant obligations (or,
where compliance failed, in scoping the actual damage). The
legal outcome is fact-specific.
HDS facilitated CHUS
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
Implementer
controller documented
Rely on the audit and version evidence in any liability dispute; the
legal posture is yours.
processor documented
📄 dpa
Maintain your own records to evidence compliance with your processor
obligations.
Art.83 General conditions for imposing administrative fines draft
Supervisory authorities must ensure fines are effective, proportionate and
dissuasive, up to the prescribed ceilings.
Pryv platform out-of-scope
Fines are regulator-side. Pryv has no role in fine calculation
or imposition. Pryv-side data + this matrix help the controller
argue for mitigation under Art. 83(2) factors (degree of
cooperation, technical + organisational measures implemented,
etc.).
HDS out-of-scope CHUS
Fines are regulator-side; HDS has no role in their calculation or
imposition. The platform's data and this matrix help a controller argue
for mitigation under the Art.83(2) factors, such as the
technical/organisational measures implemented and the degree of
cooperation.
Implementer
controller documented
Use the platform's evidence to argue mitigation under the Art.83(2)
factors should a fine be considered.
data-subject out-of-scope
Art.44 General principle for transfers draft
Any transfer to a third country or international organisation may take
place only if the Chapter V conditions are met.
Pryv platform facilitated
The Art.44 framework
is operational — every Art.45-49 path is conditional. Pryv's
data-residency primitive is the technical enforcement layer:
when you bind a subject's data to a hosting inside the EU/EEA,
no Chapter-V analysis is needed (no transfer happens). When
transfer is intentional, the CMC capability flow records the
recipient hosting + the legal basis on the originating access's
clientData — making Chapter V compliance auditable per transfer
rather than per system.
HDS facilitated CHUS
HDS's data-residency option is the technical enforcement layer: binding a
subject to the Switzerland region keeps EU/EEA data under an adequacy
regime, so no Chapter-V analysis is needed. The US region is an
international transfer requiring an Art.45/46 mechanism (SCCs). Where
transfer is intentional, the recipient and legal basis are recorded on
the access clientData, making compliance auditable per transfer.
detail
Content and audit data stay pinned to the subject's region; a deliberate
cross-region move (e.g. choosing the US region, or a US counterparty
fetching from a CH core) is the transfer event. The controller records
the recipient and transfer basis on the access; the legal mechanism
itself is a controller/legal artefact.
- 🔒 gdpr/policies/international-transfers available on request
- 🔒 hipaa/registers/hosting-provider-attestations available on request
Implementer
controller documented
Choose residency to avoid or to deliberately ground transfers, and
record the basis for each intentional transfer.
data-subject out-of-scope
Art.45 Transfers on the basis of an adequacy decision draft
A transfer may take place where the Commission has decided the third
country ensures an adequate level of protection.
Pryv platform configurable
Configure your `auth.hostings` to declare only hostings that match
adequate-protection regimes; route subjects to them as per your
transfer policy. The per-user `hosting` exposed via
`system.users.get` proves residency for auditor questions.
Maintenance of which countries currently hold adequacy (EU-US
DPF, Switzerland, UK, etc.) is operator-side regulatory tracking.
HDS configurable CHUS
HDS's Switzerland region rests on the EU adequacy decision for
Switzerland, so routing EU/EEA subjects 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
controller's regulatory responsibility.
detail
The controller selects the CH region for subjects whose transfer it wants
to ground on adequacy; the chosen hosting per user proves residency. 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
Implementer
controller documented
Route subjects to an adequacy-covered region and track the current
adequacy landscape.
data-subject out-of-scope
Art.46 Transfers subject to appropriate safeguards draft
Absent an adequacy decision, a transfer requires appropriate safeguards
such as SCCs, BCRs or approved codes.
Pryv platform facilitated
Pryv-side artefact: record the §2 mechanism on the
transferring access's `clientData.transfer_basis` (structured
object per `context/transfer-basis-convention.md` — same
pattern as `clientData.lawful_basis` from Art.6 + `clientData.
special_category_basis` from Art.9). The Art.30(1)(e)
transfers register is then derivable in a single `jq` query
against `GET /accesses`. The SCCs / BCRs / approved-code
documents themselves remain operator/legal artefacts; Pryv
persists the references + the metadata travels with the
access version chain.
HDS facilitated CHUS
Choosing the US region (AWS) 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, and offers a DPA into which the SCCs are
incorporated. The SCC/BCR documents themselves are controller/legal
artefacts.
detail
The transfer surfaces — access-bound counterparty fetches, the US-region
residency choice, and subprocessor outbound flows — each carry the
mechanism reference on the relevant artefact. HDS persists the references
with versioning and audit; the controller concludes the safeguard
instrument.
- 🔒 gdpr/policies/international-transfers available on request
- 🔒 hipaa/registers/subprocessor-register available on request
Implementer
controller documented
📄 dpa
Conclude SCCs or another Art.46 safeguard for US-region or other
third-country transfers and record the mechanism.
processor documented
📄 dpa📄 subprocessor
Sign the SCC-bearing DPA and flow equivalent clauses down to any
subprocessor.
Art.47 Binding corporate rules draft
A supervisory authority may approve binding corporate rules meeting the
prescribed content and safeguard requirements.
Pryv platform out-of-scope
BCRs are organizational rules approved by a supervisory authority
after a formal process. No software contribution — when BCRs are
the chosen Art.46 safeguard, the operator records the BCR
reference on the transferring access's clientData (per Art.46
pattern); the BCR document itself is the operator's legal
artefact.
HDS out-of-scope CHUS
BCRs are organisational rules approved through a formal supervisory
process, with no software contribution. Where BCRs are the chosen Art.46
safeguard, the controller records the BCR reference on the transferring
access; the BCR document is the controller's legal artefact.
Implementer
controller documented
If relying on BCRs, obtain approval and record the reference on the
transferring accesses.
data-subject out-of-scope
Art.48 Transfers or disclosures not authorised by Union law draft
A third-country court or administrative order to transfer or disclose data
is recognised or enforceable only on the basis of an international
agreement.
Pryv platform out-of-scope
Resistance to extraterritorial subpoenas is a legal posture, not a
software control. Pryv's audit log will record any forced
disclosure executed under the access primitive (which is the only
way data leaves the system), making the disclosure documentable
after the fact. The decision of whether to comply / contest is
legal counsel's, not Pryv's.
HDS out-of-scope CHUS
Resisting extraterritorial orders is a legal posture, not a software
control. Because the access primitive is the only path data leaves the
system, the audit log documents any forced disclosure after the fact; the
decision to comply or contest is the controller's counsel's.
Implementer
controller documented
Decide, with counsel, how to respond to any third-country order; the
audit log documents any disclosure made.
data-subject out-of-scope
Art.49 Derogations for specific situations draft
Absent adequacy or safeguards, a transfer may rest on one of the enumerated
derogations, such as explicit consent or contract performance.
Pryv platform facilitated
Each Art.49 derogation
requires per-instance recording. Pryv pattern: mint a purpose-
specific access per derogation invocation with
`clientData.transfer_derogation = "art_49_1_a_consent"` etc.;
execute the transfer; revoke. The audit trail then anchors the
derogation rationale to the specific data movement.
HDS facilitated CHUS
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
Implementer
controller documented
Establish that a derogation applies, record it per transfer, and limit
the transfer to that purpose.
data-subject out-of-scope
Art.50 International cooperation for the protection of personal data draft
The Commission and authorities are to develop international cooperation
mechanisms for effective enforcement.
Pryv platform out-of-scope
International-cooperation development is a regulator-level
activity. No software contribution; no implementer obligation
arises from this Article alone.
HDS out-of-scope CHUS
Developing international-cooperation mechanisms is a regulator-level
activity with no software contribution and no implementer obligation
arising from this Article alone.
Implementer
controller out-of-scope
data-subject out-of-scope