Data Retention and Privacy Policy
This document defines data retention periods and privacy/compliance alignment for CepatEdge. It is written for institutional review (e.g. university IT, data protection officers) and for operational clarity. Technical controls are described in Security Overview.
1. Scope
- In scope: User accounts, maintenance requests, attachments, sessions, audit-related data, backups, logs.
- Out of scope: Third-party services (e.g. email provider) — governed by their policies; we only retain what we send (e.g. delivery logs if the provider supplies them).
2. Data Retention (Default Policy)
| Data category | Retention period | Rationale / notes |
|---|---|---|
| User account data | Account lifetime + 30 days | After deletion/offboarding, 30-day grace for restore requests and audit. |
| Maintenance requests | Indefinite (or per institution) | Core business data; can be shortened by institution (e.g. archive after N years). |
| Attachments (R2) | Same as related request | Deleted when request is deleted or per retention override. |
| Sessions | Per user/timeout config; max 30 days | Server-side session storage (Durable Objects); automatic cleanup. |
| Audit / security logs | 7 years (compliance-oriented) | Aligns with common institutional and regulatory expectations. |
| Application/error logs | 30–90 days (configurable) | Operational debugging; reduce to 30 days if no longer needed. |
| Database backups | 30 days (Neon default) | Point-in-time recovery window; see Runbook for R2 backup copy. |
| R2 backup copies | Per backup strategy (e.g. 30–90 days) | If backups are copied to R2 (auto or manual); see runbook. |
| Temporary/cache data | 24 hours or TTL | Durable Object and cache TTLs; no long-term retention. |
Institution override: The deploying institution may define shorter or longer retention for specific categories (e.g. maintenance requests, logs). Implementation may require configuration or one-off scripts; document any override in the institution’s own policy and in operational runbooks.
3. Privacy and Compliance Alignment
3.1 Principles
- Data minimization: Only collect and retain what is necessary for the maintenance workflow, security, and compliance.
- Purpose limitation: Data is used for system operation, workflow (create/approve/assign/complete), audit, and support — not for unrelated marketing or profiling.
- Access control: Role-based access (RBAC); access to personal data limited by role and permission (see Security Overview).
3.2 Data subject rights (e.g. GDPR-style)
- Access: Users can request a copy of their data (profile, their maintenance requests, their activity where logged). Provide via export or admin support process.
- Rectification: Users can update profile/settings; corrections to request content depend on workflow (e.g. only before approval).
- Erasure: Account deletion should trigger deletion or anonymization of user data and, where feasible, references in requests/logs; retention may still apply for audit/compliance (e.g. 7 years for security-relevant logs).
- Portability: Export of user data in a machine-readable format (e.g. JSON) — implement as admin or self-service export if required by institution.
Document the exact process (who handles requests, SLA) in institution-facing docs (e.g. docs/university/for-institution/).
3.3 Lawful basis and consent
- Contract/legitimate interest: For institutional deployment, processing is typically under contract (employment/university relationship) or legitimate interest (maintenance management, security).
- Consent: Where required (e.g. non-essential communications), obtain and record consent; document in privacy notice or institution policy.
3.4 Breach notification
- 72-hour notification: If the institution is in a jurisdiction requiring breach notification (e.g. GDPR), define internal process to assess and notify within the required window.
- Internal process: Detection → assessment → containment → notification (see Runbook and Security Overview – Incident Response).
3.5 Vendor/subprocessor alignment
- Cloudflare (Workers, Pages, R2, Durable Objects): See Cloudflare’s DPA and privacy documentation.
- Neon (PostgreSQL): See Neon’s DPA and data residency options.
- Email provider: If used for notifications, ensure DPA and retention align with institution policy.
Keep a short subprocessor list (name, purpose, location, link to DPA) for institutional audits.
4. Operational Notes
- Backups: Backups (Neon, and any R2 copies) are part of retention; ensure backup retention and encryption match this policy (see Runbook).
- Deletion in practice: User deletion should cascade to sessions and, where policy allows, to anonymization of user references in requests/logs; attachments and request metadata may be retained per retention table for audit.
- Review: Review this policy periodically and when the institution’s or regulator’s requirements change.
5. References
- Security Overview — Controls, encryption, RBAC, incident response.
- Runbook — Backups, recovery, incidents.
- University handover / for-institution — Where to add institution-specific privacy/retention wording.