Data Retention Policy
Document status: Approved | Version: 1.0 | Effective: March 2026
Owner: Spectrum Dynamics CIC | Review cycle: Annually or upon material change
Purpose
This policy defines how long SpektraBot retains personal data, why, and when it is deleted. It implements the UK GDPR storage limitation principle (Article 5(1)(e)) and the ICO Age Appropriate Design Code (Children's Code) Standard 8 requirement to "collect and retain only the minimum amount of personal data you need to provide the elements of your service in which a child is actively and knowingly engaged."
SpektraBot processes children's educational data. Our retention approach must balance two obligations:
- Minimise data — delete what is no longer needed
- Serve the child's best interests — preserve continuity of support across their SEND journey
A single, flat retention period fails both tests. Deleting everything after a fixed period destroys the long-term support value that justifies processing the data in the first place, while retaining everything indefinitely violates data minimisation. Our tiered model resolves this tension by matching retention to purpose.
Legal basis
| Regulation | Requirement | How we comply |
|---|---|---|
| UK GDPR Art. 5(1)(e) | Data kept no longer than necessary for its purpose | Tiered retention matched to purpose (see below) |
| UK GDPR Art. 5(1)(c) | Data minimisation — adequate, relevant, not excessive | Each tier collects only what its service element requires |
| UK GDPR Art. 17 | Right to erasure | Users may request account deletion at any time |
| ICO Children's Code Std. 7 | High privacy by default | Retention defaults are the minimum for each tier |
| ICO Children's Code Std. 8 | Minimise data per service element | Each tier maps to a distinct service element |
| Children Act 2004 s.11 | Safeguarding duty | Safeguarding records retained indefinitely |
| KCSIE 2024 | School safeguarding record-keeping | Flagged content preserved for statutory purposes |
Retention tiers
SpektraBot differentiates retention by service element, as required by Children's Code Standard 8. Each data type serves a different purpose and has a proportionate retention period.
Tier 1: Chat conversations
| What | Messages, AI responses, conversation metadata |
| Purpose | Provide contextual AI guidance within a conversation |
| Retention | 90 days from last activity (the conversation's updatedAt timestamp) |
| Clock | Resets each time a message is sent in the conversation |
| Deletion | Hard delete of conversation and all associated messages |
| Justification | Once a conversation goes dormant, the immediate guidance purpose is fulfilled. 90 days provides reasonable time for users to revisit recent conversations, export useful content to their Binder, or pick up where they left off. |
Why updatedAt, not createdAt: A parent may have an ongoing conversation about their child's EHCP review over several weeks. Deleting from creation date would destroy active conversations mid-use. Activity-based retention aligns with the Children's Code requirement that data is retained while the child is "actively and knowingly engaged" with that service element.
Tier 2: Child support memories
| What | ChildMemory records — facts the bot remembers about a child's needs, preferences, and SEND context |
| Purpose | Provide continuity of support across conversations — the bot's core long-term value |
| Retention | Account lifetime: until account closure or 12 months of account dormancy |
| Clock | User's lastLoginAt timestamp |
| Deletion | Soft-delete (30-day grace period), then hard delete |
| Justification | SEND support is a journey spanning years (EHCPs run from 0–25). Memories enable the bot to provide personalised, context-aware guidance over time. Deleting them after 90 days would force parents to re-explain their child's needs in every conversation, undermining the service's purpose and the child's best interests. |
Schema design: ChildMemory records use onDelete: SetNull on their sourceConversationId foreign key. When a Tier 1 conversation is deleted, the memories extracted from it survive — the conversation transcript is gone, but the distilled facts remain. This is analogous to a professional taking notes during a meeting: the recording is deleted, but the action items persist.
Tier 3: User profiles and accounts
| What | User accounts, child profiles, preferences, binder items |
| Purpose | Maintain the user's identity and their children's educational context |
| Retention | Account lifetime: until the user requests deletion or 12 months of dormancy |
| Clock | User's lastLoginAt timestamp |
| Deletion | Account deletion cascades to all associated data (children, memories, conversations, binder items) |
| Justification | Necessary for contract performance (GDPR Art. 6(1)(b)). Without a user account, the service cannot function. |
Tier 4: Safeguarding records
| What | Content flagged by the crisis detection system, safeguarding referrals |
| Purpose | Statutory safeguarding duty and audit trail |
| Retention | Indefinite (until no longer required for safeguarding purposes) |
| Clock | N/A |
| Deletion | Manual review only — not subject to automated deletion |
| Justification | Children Act 2004 s.11 and Keeping Children Safe in Education 2024 require organisations to maintain safeguarding records. These records may be needed for ongoing child protection investigations, court proceedings, or serious case reviews. |
Retention summary
| Data type | Retention period | Deletion trigger | Method |
|---|---|---|---|
| Chat messages & AI responses | 90 days from last activity | Automated (CronJob) | Hard delete |
| Conversation metadata | 90 days from last activity | Automated (CronJob) | Hard delete |
| Child support memories | Account lifetime | Account closure or 12-month dormancy | Soft delete → 30-day grace → hard delete |
| User profiles | Account lifetime | User request or 12-month dormancy | Hard delete (cascades) |
| Child profiles | Account lifetime | Parent account deletion or 12-month dormancy | Soft delete → 30-day grace → hard delete |
| Binder items | Account lifetime | Account closure | Hard delete (cascade) |
| Safeguarding flags | Indefinite | Manual review | N/A |
| Advocate case data | 30 days post-closure | Automated | Hard delete |
| Anonymised analytics | Indefinite | N/A | No PII — not subject to GDPR |
| Database backups | 30 days rolling | S3 lifecycle policy | Automatic expiry |
Dormancy process
When a user account has been inactive for 12 months (no login):
- Day 0: Account marked as dormant
- Day 0: Notification email sent with 30-day warning
- Day 30: If no login occurs, account and all associated data are queued for deletion
- Day 30: Second notification confirming deletion has been scheduled
- Day 60: Data permanently deleted
Users can reactivate at any time by logging in during the 30-day warning period. Logging in resets the dormancy clock.
Right to erasure
Users may request deletion of their account and all associated data at any time. Upon receiving a valid erasure request:
- Account is immediately deactivated
- All personal data is deleted within 30 days
- Safeguarding records are excluded from erasure (GDPR Art. 17(3)(d))
- Confirmation email is sent upon completion
- Database backups containing the data expire naturally within 30 days
Automated enforcement
Retention is enforced by a Kubernetes CronJob (spektrabot-data-retention) that runs daily:
- Conversation cleanup: Deletes conversations where
updatedAtis older than 90 days, in batches of 5,000 to avoid database performance issues - Memory cleanup: Hard-deletes ChildMemory records that were soft-deleted more than 30 days ago
- Logging: Each deletion run logs the count of records deleted per type for audit purposes
The CronJob is defined in the Helm chart (helm/spektrabot/templates/cronjob-data-retention.yaml) and configured via the DATA_RETENTION_DAYS environment variable.
Third-party data processors
| Processor | Data shared | Their retention | Our control |
|---|---|---|---|
| Azure OpenAI (UK South) | Chat messages (for AI response generation) | 0 days (abuse monitoring exemption applied for) | Contractual DPA; no training on our data |
| Resend | Email addresses (transactional emails only) | Per their DPA | Minimum necessary; no marketing |
| Civo (hosting) | All data (infrastructure provider) | Our retention policy applies | Data stays in UK; encrypted at rest |
Backups
Database backups are taken every 6 hours and stored in Civo Object Storage (UK) with a 30-day lifecycle policy. When personal data is deleted from the live database, it persists in backups for up to 30 days before the backup containing it expires. This is documented in our privacy policy.
In the unlikely event a backup must be restored, any data that should have been deleted during the backup period will be re-deleted by the next CronJob run (within 24 hours).
Review and updates
This policy is reviewed:
- Annually as part of the DPIA review cycle
- Upon material change to data processing activities
- Upon regulatory change affecting children's data or SEND services
Changes are version-controlled in the project repository and published to docs.spektrabot.co.uk/compliance/data-retention.