ADR-0016: Data Retention, Disposal & Privacy (FADP / GDPR)¶
- Status: accepted
- Date: 2026-06-17
- Deciders: Nicolas Burri
- Relates to: ADR-0001, ADR-0013, ADR-0014; GAP-06; security NFRs → GAP-10
- Refined by: ADR-0040 (disposal-due surfacing — closure-anchored retention, scope-level legal hold), ADR-0042 (disposal execution — document tombstoning, single-actor hard-gated destruction)
Engineering decision to support compliance. Actual legal determinations — retention durations, what is exempt, whether a given erasure request is refused — are the operating organization's DPO / regulatory affairs. LQMS provides the mechanisms to implement their policy.
Context¶
Three forces conflict: ISO 13485 §4.2.5 (retain records for a defined period), our immutable audit trail / signatures / content blobs, and data-protection law (Swiss revised FADP and EU GDPR — right to erasure, minimization, storage limitation).
The resolving facts:
- Retention outweighs erasure during the retention period. For records held under a legal retention obligation, the right to erasure is disapplied (GDPR Art. 17(3)(b)/(e); FADP analogues). Medical-device retention is long: EU MDR ≥ 10 years (15 for implantables); FDA QSR/QMSR ≥ 2 years or device life. So the audit trail and signatures stay intact for the full retention period — they are not erased on request.
- Attribution is pseudonymous by design (ADR-0013): audit events, approvals, and signatures reference a stable internal user id; human-readable PII (name, email) lives only in the user record. PII can therefore be severed without breaking record integrity.
- Bounded data scope: as a QMS tool, LQMS holds staff identity, not patient/ end-customer data (that is product data, out of scope) — keeping the data-subject set small.
Deletion genuinely becomes necessary only in narrow cases: end of retention; personal data with no retention basis (invited-but-never-participated users, profile extras, PII leaked into free-text); non-regulated scopes; and minimization corrections. The common response to an erasure request touching retained records is a documented refusal citing the retention obligation, not erasure.
Decision¶
- Data minimization: store only the identity data needed for attribution (stable subject, display name, email) plus what regulated records require; nothing more. Lawful basis is legal obligation / employment, not consent (so consent-withdrawal erasure does not apply).
- Retention: retention periods are configurable per document/record type and scope, with a defined retention-start event; the system computes a disposal-due date. Durations (e.g. MDR 10/15 years) are configured by the organization.
- Legal hold can be applied to a scope or record set and suspends disposal regardless of retention expiry.
- Disposal at end of retention is deliberate, authorized, and audited (not automatic): records are flagged disposal-due; an authorized actor reviews and executes; a disposal record (what / when / who / policy) is retained; legal hold blocks it.
- Erasure is qualified and narrow:
- Data under a retention obligation is retained, not erased, during retention; the system can produce a "what personal data we hold about this individual, and on what basis" report to support a documented refusal and access requests.
- Where erasure is warranted (no-retention-basis data, non-regulated scopes, end-of-retention, minimization corrections), it is performed by physically deleting the user record where nothing retained references it, or anonymizing it (PII → non-identifying tombstone, internal id and references preserved) where retained records still reference it — keeping record integrity and historical attribution-token intact.
- Rectification: identity claims (name, email) are refreshed from the IdP (ADR-0013).
- Signature manifestation captures the signer's name as a snapshot at signing (part of the immutable signed record), retained under the legal basis during retention and disposed at end of retention (refines REQ-SIG-004).
- Encryption-at-rest / crypto-shredding deferred to GAP-10 (security NFRs). For now erasure relies on physical deletion + user-record anonymization, which suffices for directly-deletable storage.
Consequences¶
- The ADR-0012 permission set gains retention/disposal permissions (e.g.
MANAGE_RETENTION,APPLY_LEGAL_HOLD,DISPOSE_RECORDS,ERASE_PERSONAL_DATA). - Schema: retention policy config (per type/scope), retention-start + disposal-due, legal-hold flags, disposal records, user-record anonymization support.
- Interaction with backups (REQ-BAK): backup archives are a place disposed/erased data can linger; handling that cleanly is part of the deferred crypto-shredding / GAP-10 work and is noted there.
- All retention-policy changes, legal holds, disposals, and erasures are audited (REQ-AUD-001).
Requirements¶
Introduces STR-021 and the REQ-DPR group (pending requirements baseline v1.1); refines REQ-SIG-004 (snapshot name).