Privacy Policy
Digital Health Corner — Project Directory Effective: 2026-04-29 · Concept reference: §7
Note. This text is a draft. Binding versions are released by the curatorium and the data-protection officer before go-live. Sections marked
[TBD: …]are still to be supplied. The German version (PRIVACY.de.md) is the binding text per CoC §12.
1. Data Controller
The controller in the sense of the GDPR is:
- [TBD: full legal name of the operating body]
- Address: [TBD: street, postcode, city, country]
- Email: [TBD: contact-email@…]
- Phone: [TBD: optional]
2. Data Protection Officer
[TBD: name and contact of the DPO if appointed; otherwise: "No DPO is appointed; appointment is not mandatory under Art. 37 GDPR."]
3. What data is processed
The DHC Project Directory processes only the data needed to fulfil the purpose laid down in concept §3 (making projects visible and allowing personal contact):
| Category | Content | Legal basis |
|---|---|---|
| Member account | email, name, organisation, organisation domain, role | Art. 6(1)(b) — performance of contract |
| Profile content | the 13 fields per concept §5.1 | consent at profile creation (Art. 6(1)(a)) |
| Authentication data | passkey credential IDs and public keys, an optional device label you choose, transports list, last-used timestamp, backup-code bcrypt hashes (separate batches for passkey and TOTP factors), AES-256-GCM-encrypted TOTP seed (if TOTP is enabled), magic-link / recovery tokens, session tokens with their auth-method tag and MFA-verification timestamp | Art. 6(1)(b) |
| Biometrics | never processed by the platform. Fingerprint or face-recognition data, when you use a passkey, stays on your device — the platform only ever sees the resulting cryptographic signature. | not applicable |
| Audit log | actor, action, timestamp of administrative events | Art. 6(1)(f) — legitimate interest, traceability (concept §7.4) |
| Invitations | email address of invitee, optional note, status | Art. 6(1)(b) |
| Code-of-Conduct acceptance | date, version | Art. 6(1)(c) — documentation duty |
No special-category data under Art. 9 GDPR is processed. Classified content is forbidden by CoC §4.
4. Purposes of processing
- Operating the platform (rendering profiles per the visibility model, concept §4.3)
- Authenticating members (passkey-based sign-in; magic-link for the initial email verification and for recovery)
- Communication with members (invitations, contact requests)
- Security and abuse prevention (audit log, burst detection)
- Fulfilment of legal obligations (consent records)
5. Recipients and processors
Personal data is shared only with:
- Hosting provider: [TBD: ZAP server provider, Frankfurt am Main, Germany] — processor under Art. 28 GDPR
- Email transport: [TBD: SMTP provider with EU-based servers]
- Within the platform: other members within the profile-owner's chosen visibility tier (Tier 1/2/3 per §4.3)
No data is transferred to third countries outside the EU/EEA. All servers are located in Frankfurt am Main, Germany.
6. Retention
| Data type | Retention |
|---|---|
| Account + profiles | until the member deletes (Art. 17) |
| Passkey credentials (public key + metadata) | until removed by the member or until account deletion |
| TOTP seed (AES-256-GCM encrypted) | until disabled by the member or until account deletion |
| Backup-code hashes (passkey + TOTP, separate batches) | until consumed or until regenerated |
| Magic-link tokens (initial email verification + magic-link sign-in) | 15 minutes |
| Curator-mediated recovery tokens | 60 minutes, single-use |
| Session tokens | 30 days rolling, deleted on inactivity |
| Invitations | 30 days after issue or until accepted |
| Audit log | [TBD: retention period, recommend 24 months, then anonymised] |
| Stale-profile flag | 12 months without update |
After account deletion, anonymised traces remain in the audit log (actor-id nulled, email removed) where required for traceability.
7. Your rights
Under the GDPR you have the following rights:
- Art. 15 — Access. On request you receive a copy of all data we hold about you. The most relevant fields are also visible in "Settings" while signed in.
- Art. 16 — Rectification. Profile data is editable directly; other corrections via the contact in §11.
- Art. 17 — Erasure. You can delete your account at any time (Settings → Delete account). Deletion covers profile, sessions and contact requests.
- Art. 18 — Restriction. On request.
- Art. 20 — Data portability. JSON export via Settings.
- Art. 21 — Objection. Against processing based on Art. 6(1)(f) (audit log).
- Right to lodge a complaint with the competent supervisory authority: [TBD: relevant German data-protection authority — for a Hessen-based seat, "Der Hessische Beauftragte für Datenschutz und Informationsfreiheit"]
8. Cookies
The DHC Project Directory uses only strictly necessary and functional comfort cookies. There are no tracking, analytics or marketing cookies, no third-party cookies, no external CDN-served fonts, and no embedded analytics services such as Sentry, Hotjar or Plausible. Nothing on the platform calls outside the EU.
Functional cookies (shared across apex and app)
| Name | Purpose | Lifetime | Type | Set by | Domain | SameSite | Secure |
|---|---|---|---|---|---|---|---|
dhc_locale | stores the chosen UI language | 1 year | functional (comfort) | server | .digitalhealthcorner.eu | Lax | yes |
dhc_theme | stores the chosen light / dark preference | 1 year | functional (comfort) | server | .digitalhealthcorner.eu | Lax | yes |
dhc_notice_dismissed | remembers that the user has seen the cookie information bar | 1 year | functional (comfort) | server | .digitalhealthcorner.eu | Lax | yes |
These three cookies contain no personal identifiers and no tracking
IDs. They store only the user's own UI preference. The leading dot
in the Domain attribute is intentional — the cookies are shared
between the marketing site (digitalhealthcorner.eu) and the
application (app.digitalhealthcorner.eu), so a member's language
and theme choice carry across the two surfaces. They are not visible
to any other domain.
A consent banner under §25 TDDDG (the German implementation of the ePrivacy directive) is not required — these cookies fall under the "strictly necessary for the requested service" exception.
Sign-in cookies (application route only)
The application at app.digitalhealthcorner.eu additionally sets the
sign-in cookies issued by the Auth.js v5 library. These remain
host-only (they do not carry the .digitalhealthcorner.eu Domain
attribute) so the marketing site never sees them.
| Name | Purpose | Lifetime | Type | Domain |
|---|---|---|---|---|
authjs.csrf-token | CSRF protection on the sign-in form (passkey + magic-link) | session | strictly necessary | app.digitalhealthcorner.eu |
authjs.session-token | the signed-in session after a successful passkey assertion | 30 days | strictly necessary | app.digitalhealthcorner.eu |
authjs.callback-url | post-login redirect target | session | strictly necessary | app.digitalhealthcorner.eu |
Right to refuse
You may delete these cookies at any time via your browser settings. The platform's main content remains usable without them — you would just lose the comfort preferences (language, colour scheme) and would have to sign in again on the application route. No content is gated behind cookies.
9. Security measures
- TLS on all connections.
- Two-factor authentication on every sign-in, via one of two equal
paths (concept §7.3 as amended by ADR 011):
- Passkey path (FIDO2 / WebAuthn): possession (your device) + inherence (biometric / PIN) in a single ceremony, phishing-resistant. The cryptographic public key bound to your account is not by itself personal data, but it appears in the export below alongside the device label you chose.
- Magic-link + TOTP path: possession (your email) via the magic
link + knowledge / possession (6-digit code from an authenticator
app). Chosen by members on hardened enterprise PCs that cannot
register a passkey. The TOTP seed is encrypted at rest with
AES-256-GCM (key in the
MFA_KEYenvironment variable); the plaintext seed never leaves the server, and the encrypted blob is NOT included in the data export — it would be useless to you without the server key.
- At least one 2FA factor is mandatory; single-factor sign-ins are not accepted anywhere on the platform.
- Magic-link is also used as the onboarding email-verification step (15-minute window). If you lose both factors, recovery requires a curator to issue a one-time link with a 60-minute window after an out-of-band identity check; all events are recorded in the audit log.
- Backup codes (8 per factor, separate batches for passkey and TOTP) are shown once and stored server-side only as bcrypt hashes; consumed codes are invalidated.
- Per-user session duration (30 or 90 days) is selectable; changes also clamp existing sessions downward.
- Encrypted database backups; [TBD: backup strategy + retention].
- Audit log of security-relevant actions (passkey + TOTP registration and removal, MFA verification, failed codes, backup-code use, curator-mediated recovery).
10. Profile visibility (concept §4.3)
Profiles are visible only to a restricted audience based on the chosen visibility tier:
- Tier 1 (Open): all authenticated members
- Tier 2 (Domain): only members of the same organisation domain
- Tier 3 (Request): only name, tags and domain are visible upfront; full data only after individual approval by the profile owner
These tiers are enforced technically and cannot be circumvented by multi-account or scraping (cf. CoC §6).
11. Contact for data-protection requests
[TBD: dedicated privacy email, e.g. privacy@digitalhealthcorner.eu]
12. Changes to this policy
Substantive changes are announced to members at least 14 days in advance; non-substantive edits (typos, editorial clarifications) are made silently with an updated effective date above.