Trust Center

Retention, legal hold, and deletion for student-report data

This page explains what Whispr EDU retains, for how long, what the legal-hold and deletion paths look like, and where the school's own record-keeping policy takes over. Retention is primarily a school-policy decision shaped by national law, school-board guidance, and safeguarding practice — Whispr provides the operational controls; the school owns the policy.

Policy first

Retention is a school-policy decision, not a single product setting

How long student-report data is kept should follow the school's record-keeping policy, safeguarding-file practice, and local law (national child-protection law, GDPR for EU/UK schools, KCSIE in England, equivalents elsewhere). Whispr supports the operational mechanics; it does not, on its own, set the retention rule.

What we provide

Retention metadata, legal hold, export paths, and manual deletion in supported flows

Each report carries timestamps and lifecycle metadata. Legal-hold flags block certain destructive actions while an investigation is open. Authorised handlers can export and, in supported flows, manually delete records. Account-closure handling is set in the contract.

Confirm in contract

Confirm the retention schedule with legal, your safeguarding lead, and the signed service terms

This page is informational. The retention model that binds BackPR for a given workspace is the one written into the school's signed DPA and order form (where present). Read this page together with the DPA, Terms, and Disclaimers.

Policy vs product

Retention is primarily an organisational policy decision, not a one-click guarantee

The retention period that matters legally for a given school is the period in the school's record-keeping policy and the period required by applicable law — not whatever the product happens to keep by default. Whispr operates on the school's instructions and within the controls described here; it does not replace the school's policy work, and it does not warrant that any default behaviour is appropriate for any specific jurisdiction, programme, or age group.

Product controls

The codebase supports retention metadata and legal hold; it does not perform universal auto-deletion by default

Per-record metadata

Each report carries creation timestamp, last-modified timestamp, category, assigned handler, status, and (where set) a legal-hold flag. This is the basis for any retention or deletion action a handler decides to take.

Legal-hold flag

Handlers with the right permission can place a report on legal hold. While the flag is set, the product blocks routine deletion paths to reduce the risk of an in-flight investigation losing evidence. Removing the flag is itself an audited action.

Manual deletion and export

Where the product exposes deletion, that path is a deliberate action performed by an authorised handler, not a background sweep. Exports (CSV / supported formats) are available so the school can archive records outside the product when its retention policy requires it.

Backups and replication

Backup and replication windows operated by Whispr or its sub-processors mean that deletion is logically immediate but may persist in backup snapshots for a bounded window. Persistence in backups for the standard window is not a breach of a deletion request.

Audit trail

Actions on a report (view, assign, reply, hold, export, delete) are logged. The audit trail is itself retained alongside the workspace and is intended to be available to the school for review and to BackPR for security investigations.

Anonymous-report constraint

Where a report is submitted anonymously, the product does not know who the reporter was. Whispr cannot, on the school's instruction or otherwise, look up "all reports submitted by student X" if student X chose anonymity. This is a property of the channel, not a limitation we will work around on request.

Honest scope

Deletion and export exist as operational actions, not as a full retention engine

Whispr EDU does not currently offer per-category time-based automated deletion ("delete bullying reports after 6 months, vandalism after 12, safeguarding after 25 years"). Schools needing that level of automated lifecycle should plan for periodic manual exports and deletions, and should reflect that in their record-keeping policy. We will not promise an automated retention engine that is not in the product.

Governance

Retention schedules should come from your governance model, not from product defaults

Typical inputs to a school retention schedule include: (i) the safeguarding file rule under the local jurisdiction's child-protection framework (often very long retention for serious safeguarding records); (ii) general record-keeping rules under education law; (iii) GDPR Article 5(1)(e) storage-limitation principle for EU/UK schools; (iv) parental and student rights of access, rectification, and erasure (GDPR Articles 15, 16, 17 and equivalents); (v) any specific protections for minors (GDPR Article 8 where it applies, COPPA in the US where applicable, and analogues); (vi) the school's own evidence-preservation needs for open investigations or disciplinary processes. Whispr does not advise on which combination applies; the school's safeguarding lead, DPO, and counsel do.

Account closure

Account closure and post-termination handling belong in the contract

What happens to workspace data when the relationship with BackPR ends is governed by the signed service terms and DPA, not by this page. Typical patterns include: a defined export window during which authorised school admins can retrieve records; a deletion deadline after which BackPR will delete remaining workspace data from production systems; and a backup-rotation period after which deletion propagates through backup snapshots. The exact numbers in force for a given school are the ones in that school's signed agreement.

Student and parent rights

Rights of access, rectification, and erasure are handled by the school

Where GDPR or an equivalent regime gives students or parents rights of access, rectification, restriction, objection, or erasure in relation to data held in a Whispr EDU workspace, those requests should be addressed in the first instance to the school. The school is the controller for the relationship with its students and parents. BackPR, acting as processor, assists the school in responding to verified requests in line with the DPA. Where a request would require the school to break the anonymity guarantee given to anonymous reporters, the school should consider that the integrity of the channel itself depends on that anonymity holding.

Contact

Questions about retention or legal hold

Privacy and DPO requests: privacy@backpr.com. Commercial and contract questions: sales@backpr.com.