Data retention
Three things have retention rules: submissions, files, and audit logs. The rules differ by plan.
Submissions
| Plan | Retention | Behaviour at end of window |
|---|---|---|
| Free | 30 days | Hard-deleted automatically |
| Pro | Forever | Kept until you delete |
| Team | Forever | Kept until you delete |
| Scale | Custom | Configurable per form (e.g. 90d, 365d, 7y) |
"Forever" means we don't auto-delete. You can still delete individual submissions or run bulk deletes any time, and a right-to-erasure request always takes precedence (see GDPR).
On Free, the 30-day rolling window is enforced by a daily job that hard-deletes anything past the boundary. We email you 7 days before a submission first crosses the line so you have time to upgrade or export. On Free, that email is your only warning - there's no recovery once the job runs.
Each form can also set a shorter retention window under Form → Settings → Submission handling → Retention policy. Leave the field blank to use the plan default. Shorter form windows are enforced by the same daily purge job; they delete the submission and any attached files together.
Plan limits still cap the setting. A Free form cannot extend retention beyond 30 days by typing a larger number. Paid plans with unlimited default retention can use per-form windows when they want stricter privacy controls, for example deleting newsletter sign-ups after 14 days while keeping support history until manually deleted.
Files
File retention follows the parent submission. When the submission is deleted (auto or manual), attached files are deleted from object storage in the same operation.
There's no separate "file-only" retention setting on standard plans. Scale customers can configure shorter file retention than submission retention (e.g. delete files after 90 days but keep the submission payload), useful when you want to retain evidence-of-receipt without retaining sensitive uploads forever.
Audit logs (Team+)
The team audit log retains:
- Sign-ins (timestamp, IP, user agent)
- Token mints, revocations
- Form mutations (create, update, archive, restore)
- Webhook mutations
- Bulk submission operations
- Membership changes (invite, role change, remove)
Retention:
- Team - 365 days
- Scale - configurable, default 365, max 7 years
These windows are the policy we hold ourselves to on request. Be aware that no scheduled job enforces them automatically today: audit log entries persist until the team is deleted, at which point they are hard-deleted with the rest of the team's data. If you need entries older than your window removed on a fixed schedule, email info@pixelandprocess.de and we will run it and confirm in writing. Once removed from the live database, an entry can still persist in a disaster-recovery snapshot until that snapshot is retired, exactly as described under backups below.
Hard delete vs. soft delete
We use both, intentionally:
| Operation | Type | Recovery window |
|---|---|---|
| Submission deleted via right-to-erasure | Hard | None |
| Submission deleted via dashboard "Delete" | Hard | None |
| Submission past auto-retention window | Hard | None |
| Submission marked as spam | Soft (it's still in spam folder) |
Forever, until deleted |
| Form archived | Soft | Restorable from archived view |
| Form deleted | Hard | None |
| Webhook deleted | Hard | None |
| Team cancelled | Soft, then the Free 30-day window applies to existing submissions | See cancellation |
The pattern: anything operationally reversible is soft-deleted; anything that touches user data under a privacy obligation is hard-deleted.
Backups and what a hard delete does not reach
A hard delete is executed against the live database and against object storage, and it is final there. The product has no backup, snapshot, or restore feature: nothing in Formspring writes, reads, or restores a backup, so neither you nor we can bring a deleted submission back through the application. If you need a copy, export before the deletion, not after.
Separately from the product, the infrastructure the service runs on keeps its own storage-level snapshots for disaster recovery. Those are a property of the hosting arrangement rather than a Formspring feature, they are held in the same EU location as the live data, and they are used only to rebuild the service after a failure - never to serve a restore request for an individual record.
That distinction matters for a right-to-erasure request, so state it plainly to your own data subjects: the record is removed from the live system immediately, and it can persist in a disaster-recovery snapshot until that snapshot is retired. We do not selectively scrub snapshots; snapshot expiry handles it. If your Art. 30 records or your own privacy notice need the exact snapshot schedule and expiry in writing, email info@pixelandprocess.de and we will confirm the current figures rather than have you quote an estimate.
Right to erasure overrides retention
Even if your plan retains forever, a right-to-erasure request triggers immediate hard-delete. There's no "but Pro keeps it" exception. See GDPR for the request flow.
Custom retention
You can pin shorter retention windows per form:
- Marketing forms: 30 days (don't keep newsletter sign-up data longer than necessary)
- Support forms: 365 days (keep enough history to handle follow-ups)
- Compliance forms: 7 years (regulated industries)
Configure under Form → Settings → Submission handling. The setting drives the daily auto-delete job. Enterprise retention windows that exceed standard plan limits are handled on Scale; email info@pixelandprocess.de if you need a contract-specific retention policy.
What about anonymized submissions?
We don't run an anonymization pipeline. Submissions are either retained in full or hard-deleted. If you need anonymized analytics, export to JSON, anonymize on your side, and delete the original.
What's next
- GDPR → - DSARs and right to erasure
- Regional hosting → - where data lives
- Sub-processors → - third parties involved
- Encryption → - what's encrypted and where