Privacy notice & data-retention policy
Last updated: 2026-05-14 · DMP §6 · Governance
Scope
The Molecular AOP Builder (molaop-builder.vhp4safety.nl) is a curator-facing
tool for proposing and approving mappings between Adverse Outcome Pathway Key Events and
biological pathways or Gene Ontology terms. It does not collect personal data from members
of the public who only browse or query the mapping database. The processing described below
applies to curators and proposers who authenticate in order to submit
mappings.
What we collect, and why
When you authenticate via OAuth and submit a proposal, the application stores:
- Your provider-prefixed username (e.g.
github:alice,orcid:0000-0003-2230-0840) — the stable identifier for your contributions. - The name you entered on the proposal form — used for attribution on approved mappings.
- Your email address — used so an administrator can contact you about an ambiguous or rejected proposal.
- Your institutional affiliation (optional) — surfaced on the public provenance record of an approved mapping.
The legal basis under the General Data Protection Regulation (GDPR) is
performance of a contract: you choose to authenticate, submit a proposal,
and consent to attribution of your contribution as part of the curation workflow. The
application requests no OAuth scope beyond what is needed to read your profile (name, email,
affiliation where available) and verify your identity. Tokens issued by the provider are
held only in your Flask session and are discarded on logout or session expiry. Once a
mapping is approved, the curator's identity is also written into the immutable provenance
fields of the mapping itself (proposed_by, approved_by_curator).
Where it lives
Personal data sit in the application's SQLite database (ke_wp_mapping.db) on a
GlusterFS-replicated volume of the VHP4Safety Strato Docker Swarm cluster. The data are not
classified as special-category personal data under GDPR Article 9. Access is restricted to
the application container and to the small set of cluster administrators with shell access
on the swarm manager nodes; transport between your browser and the application is protected
by TLS (Let's Encrypt) terminated at Traefik.
Cookies and session security
Sessions use first-party cookies marked HttpOnly, SameSite=Lax,
and Secure in production, with a thirty-minute session lifetime and a one-hour
CSRF token lifetime. No third-party analytics, advertising, or tracking cookies are set by
the application.
Retention
The application distinguishes four categories of data, each with its own retention rule:
| Category | Retention | Rationale |
|---|---|---|
Identity fields on approved mappings
(proposed_by, approved_by_curator, timestamps) |
Indefinite, for the lifetime of the mapping | Attribution is part of the public scientific provenance of every mapping; erasure of these fields would compromise the audit trail. Erasure requests are handled case-by-case by the Data Steward in coordination with the institutional Data Protection Officer (see "Your rights" below). An automated placeholder-replacement procedure is planned but not yet implemented. |
| Identity fields on pending, rejected, or withdrawn proposals | Indefinite, retained as curation audit trail | Rejected and withdrawn proposals are kept so that a curator can revisit a decision, detect duplicate submissions, and reconstruct the assessment history. The data are not used for any purpose beyond curation review. Erasure on request is straightforward because the data are not part of any public output. |
| Guest access codes (workshop logins; no personal data unless a guest associates a name) | Active until the code's stated expiry; row retained 30 days post-expiry for audit, then purged | Short-lived workshop credentials with no need for long-term retention. |
| SPARQL response cache (no personal data) | 24-hour rolling cache, automatically evicted | Performance optimisation only; rows expire by timestamp on next access. |
Your rights under GDPR
You have the right to request:
- Access to the personal data we hold about you;
- Rectification of any inaccurate or incomplete data;
- Erasure of the data we hold about you. Identity on approved mappings is part of the public scientific provenance, so erasure of those specific fields is handled case-by-case by the Data Steward together with the institutional Data Protection Officer; an automated placeholder-replacement procedure is planned but not yet shipped. Erasure of identity on pending, rejected, or withdrawn proposals is unconditional;
- Restriction of processing in specific circumstances;
- Portability of your data in a machine-readable format;
- Objection to processing on legitimate-interests grounds.
Subject-rights requests are handled by the Maastricht University Data Protection Officer, who is the institutional data controller for this application. The technical contact inside the application is the Data Steward, who prepares the response under the DPO's sign-off. Both contacts are listed below.
Contact
- Data Steward (technical contact, first point of contact): Marvin Martens · ORCID 0000-0003-2230-0840 · Department of Translational Genomics, Maastricht University. Please route subject-rights requests here first; the Data Steward forwards to the institutional Data Protection Officer for sign-off.
- Data Protection Officer (institutional controller): Maastricht University. Direct contact channel is being confirmed; in the meantime requests should be routed via the Data Steward above.
For background on roles and escalation, see docs/GOVERNANCE.md. For the full data lifecycle, see docs/DMP.md.