Data Retention and Deletion Policy
Version draft · Not published
PUBLICATION CHECKLIST — NOT YET A LIVE POLICY. [[REVIEW_REQUIRED]] Confirm the operator identity, contact channels, hosting and retention practices, legal bases, actual product behaviour and applicable Dutch/EU law. Have the document reviewed and remove this notice only when verified. Publication requires an explicit administrator action.
Data Retention and Deletion Policy
Retention principles
ArchForge should collect and retain only what is needed for defined purposes, security, legal obligations and documented operational recovery. Actual periods must match the deployed database, logs, application code, storage configuration and backups. This document is a publishable policy only after the fields below are verified.
Required data schedule
| Category | Actual retention or trigger — verification required |
|---|---|
| Active accounts, profile and credentials | {{ACCOUNT_RETENTION}} |
| Ended accounts and residual records | {{CLOSED_ACCOUNT_RETENTION}} |
| Session records and login attempts | {{SESSION_AND_LOGIN_RETENTION}} |
| Security, rate-limit and audit logs | {{SECURITY_LOG_RETENTION}} |
| Public and private Git objects | {{GIT_CONTENT_RETENTION}} |
| Issues, PRs, discussions, groups and chats | {{COMMUNITY_RETENTION}} |
| Moderation notices and evidence | {{MODERATION_RETENTION}} |
| Email delivery and notification records | {{NOTIFICATION_RETENTION}} |
| Backups and disaster-recovery snapshots | {{BACKUP_RETENTION}} |
| Webhook queues, payloads and deliveries | {{WEBHOOK_RETENTION}} |
Do not fill this table with aspirational periods. If the application cannot enforce a claimed deletion deadline, update the software and operational procedures before publication.
Requests and validation
An account holder may submit a privacy request via /settings/privacy. Access, correction, erasure, restriction and objection requests are reviewed under applicable data-protection law. An authenticated request is not automatically executed: operators may need to verify identity, resolve disputes about shared project ownership, document statutory exceptions and prevent disclosure of third-party data.
Technical limits and copies
Deleting an item from the visible interface is different from purging historical Git objects, snapshots, backups, third-party forks and external clones. We explain which copies are within our control and which are not, and document any lawful preservation. Where backups are time-limited, specify the verified rotation and restore policy before publishing.
Governance
Only authorized personnel should approve disposal or exceptional preservation, and an audit record should capture any legally significant deviation. Incident-response evidence should be retained only for an appropriate, documented period.
Changes and version history
This policy applies from its stated effective date once published. Material changes are dated and versioned. Earlier versions remain available to administrators for audit, and any notice or renewed agreement required by applicable law is handled separately. Questions and legally valid notices may be sent using the contact details in the Legal Notice.