%202.png)
GDPR Article 5(1)(e) and POPIA Section 14 require organisations to retain personal data only as long as necessary, then delete or de-identify it in a way that prevents reconstruction. The exposure is real — 30% of large organisations had a data privacy incident in the past year, and regulators actively enforce against over-retention. This guide turns those obligations into a defensible policy for research teams.
A secure retention and deletion policy for participant data is a documented, enforced set of rules that does two things. First, it limits how long identified or identifiable participant data is kept, consistent with the storage limitation principle in data protection law. Second, it ensures timely, verifiable disposal — or irreversible de-identification — using appropriate sanitisation methods, covering backups and vendor-held copies too.
What "participant data" actually covers
Participant data in a research context covers more ground than most people realise. It includes contact and recruitment information (phone numbers, WhatsApp IDs, email addresses), consent records and privacy notices, survey responses and interview transcripts, uploaded media like images and voice notes, diary entries and schedule metadata, incentive and payment records, quality and fraud-check evidence, system logs, and any exports or analyst working copies sitting on someone's laptop.
The legal backbone comes from two primary frameworks. GDPR Article 5(1)(e) establishes storage limitation: personal data must be kept "no longer than is necessary" for the processing purpose. POPIA Section 14 mirrors this — once an organisation is no longer authorised to retain personal information, it must destroy, delete, or de-identify it "as soon as reasonably practicable" in a manner that prevents reconstruction.
What the laws require
GDPR storage limitation and erasure
The GDPR does not prescribe specific retention periods. That is the point. The ICO's storage limitation guidance makes clear that there are no universal time limits. You must set your own periods, justify them, review them periodically, and delete or anonymise data when the purpose no longer applies.
Article 17 gives individuals the right to erasure ("right to be forgotten"), which obliges controllers to erase personal data without undue delay when certain grounds apply. If data was made public, you must take reasonable steps to inform other controllers of the erasure request. Critically, the ICO recognises that for backups, immediate secure deletion may not be technically feasible. In those cases, putting data "beyond use" is an acceptable interim measure, provided strict access controls and overwrite schedules are in place. The GDPR does allow longer retention for scientific research under Article 89(1), but only with appropriate safeguards. The ICO warns explicitly against misusing "archiving in the public interest" as a label to keep ordinary business records indefinitely.
POPIA Section 14 (South Africa)
POPIA Section 14 prohibits retaining personal information any longer than is necessary, unless required by law, contract, or for a lawful purpose the data subject has consented to. Like the GDPR, POPIA allows retention for research or statistical purposes with safeguards. The critical requirement: once retention is no longer justified, destruction or de-identification must happen as soon as reasonably practicable, and the method must prevent reconstruction of the information.
Building a defensible retention policy
Classify participant data by purpose and identifiability
Before setting any retention periods, map every type of participant data your projects generate. Record this classification in your Record of Processing Activities (ROPA). Both GDPR and POPIA expect lifecycle documentation for each dataset.
Map each class to a retention trigger
"End of project" is not a defensible retention trigger on its own. Tie retention to the last specific action that justifies keeping the data — final report delivery, tax law expiry for incentives, claims limitation period for consent records. The ICO emphasises you must justify and document each period. If you cannot articulate why a specific data class needs to exist at a given point, that is your signal to delete.
Set concrete retention windows
Adapt to your sector laws and risk profile. Don't rely on round-numbered defaults if shorter is justifiable.
Illustrative defaults for a commercial research project
| Data class | Suggested retention | Notes |
|---|---|---|
| Contact / recruitment info | Project end + 6–12 months | Covers callbacks, complaints. Separate panel members into new lawful-basis context if keeping longer. |
| Consent records | 3–6 years (jurisdiction-dependent) | Needed for regulator inquiries. Segregate from research content. Restrict accessible fields. |
| Raw media (voice, video, images) | Through analysis, then delete or anonymise | For research archiving, apply Article 89(1) or POPIA Section 14(2) safeguards. |
| Transcripts | Same as raw media | Anonymise exemplar content for reports if needed beyond analysis. |
| Incentive / payment records | 5–7 years (tax / accounting) | Segregate from research content. Minimise fields retained. |
| System logs and quality flags | 90–180 days | Unless security or fraud-control needs justify longer. Pseudonymise where feasible. |
| Exports and working copies | Shorter than source systems | Enforce re-pulls for fresh analysis. Ban local hoarding on personal drives. |
| Backups | Per disaster-recovery policy | Apply "beyond use" controls. Ensure expiry per schedule. Disclose in erasure responses. |
The practitioner consensus. Retention choices vary widely based on claims windows and sector obligations. Justify your periods in privacy notices without fake precision, and review them regularly.
Deletion methods that stand up to audit
Setting retention periods is half the problem. The other half is proving you actually deleted the data when the clock ran out.
Application-level deletion
Best for: Cloud-hosted research platforms — the most common approach.
- Remove rows, documents, and files from production systems.
- Detach any keys or indexes linking pseudonymous codes back to identities.
- Verify the deletion in your ROPA and audit logs.
Platforms with configurable retention, encryption at rest, role-based access controls, and audit logging make this significantly easier to operationalise.
Cryptographic erasure (crypto-shredding)
Best for: Encrypted SSDs and cloud volumes where physical destruction isn't possible.
- If data is encrypted with field-level or full-disk encryption, destroying the encryption keys renders it unrecoverable.
- NIST SP 800-88 Rev.2 recognises cryptographic erase as a valid sanitisation technique when implemented correctly.
- Practitioners on r/CMMC confirm cryptographic key destruction is widely accepted as a practical sanitisation approach.
Media sanitisation per NIST 800-88 Rev.2
Best for: Physical devices where reuse or disposal triggers a sanitisation requirement.
- Clear: overwrites or factory resets — appropriate for low-confidentiality reuse.
- Purge: stronger techniques (cryptographic erase, secure block erase) — appropriate for moderate confidentiality.
- Destroy: physical destruction (shredding, melting, disintegration) — appropriate for high confidentiality.
Choose based on confidentiality level, media type, and whether the device will be reused or discarded.
Verification and documentation
Every deletion action needs a paper trail. NIST 800-88 Rev.2 requires verification and documentation of sanitisation. In practice, this means sample-based verification of deletion completeness and certificates of destruction tied to device serial numbers. One practitioner in an r/CMMC thread shared that deletion certificates with serial numbers are essential during audits, and that auditors specifically look for documentation linking sanitisation actions to individual storage media.
The backup problem
Backups are where most secure retention and deletion policies for participant data hit a wall. Modern backup systems often use immutable storage, meaning individual records cannot be surgically removed without breaking the integrity of the entire backup set.
The "beyond use" approach
The ICO endorses a pragmatic solution: when immediate deletion from backups is technically infeasible, put the data "beyond use." This means no indexing, no access, and no restore except for genuine disaster recovery; strict access controls; and a documented overwrite or expiry schedule. European CISOs discussing this on Reddit report that the "beyond use" approach is widely adopted across organisations subject to GDPR. The practical advice: don't promise instant purge from backups in your privacy notice. Instead, set short backup retention cycles where feasible and disclose the backup behaviour in erasure responses.
Communicating this to participants
When responding to erasure requests, explain: the data has been deleted from all active systems; backup copies exist but are placed beyond use; these backup copies will expire according to the documented schedule. Backups are processing under both GDPR and POPIA. Treating them as somehow exempt is incorrect and a common compliance gap.
Research archiving: when you can keep data longer
Both GDPR and POPIA allow extended retention for legitimate scientific, historical, or statistical research purposes. But the exemption is narrower than many organisations assume. To retain participant data for research archiving under Article 89(1) or POPIA Section 14(2), you need pseudonymisation or anonymisation, separated key files, restricted access controls, no incompatible re-use, and a DPIA covering long-term retention. The ICO's research provisions guidance is clear: you cannot use the research exemption to justify keeping data "just in case" it might be useful someday. The archiving purpose must be genuine, documented, and the safeguards must be real.
Vendor contract must-haves
Your retention and deletion policies are only as strong as the contracts governing your data processors. GDPR Article 28(3)(g) requires that processors, at the controller's choice, delete or return all personal data at the end of services and delete existing copies unless law requires retention.
- AExplicit deletion or return obligations. Specify timelines (for example, within 30 days of service termination).
- BDeletion method specifications. Don't leave the method ambiguous. Specify whether app-level deletion, cryptographic erasure, or media sanitisation per NIST 800-88 is required.
- CSubprocessor flow-down. The same deletion obligations must cascade to every subprocessor — cloud infrastructure, transcription services, analytics tools.
- DDeletion attestations. Require written confirmation of deletion, with date, method, and scope.
- E"Beyond use" commitments for backups. If the processor uses immutable backup storage, the DPA should specify isolation controls, access restrictions, and the backup expiry schedule.
Evaluating whether a research platform enforces these controls in practice matters as much as the contract language. Compare pricing and feature sets across platforms with an eye toward configurable retention, encryption, audit logging, and data residency options (EU or South Africa).
Risks and signals regulators care about
Over-retention is actively enforced
Regulators don't just enforce against data breaches. They enforce against over-retention itself. The EDPB-published decision cited earlier confirms that exceeding your own stated retention windows — even when the original period was defensible — constitutes a breach of Article 5(1)(e).
Common pitfalls
"Just in case" hoarding. Keeping data without a defined purpose or period violates storage limitation. This is the most common finding in regulatory audits of retention practices. Forgetting exports and working copies — analysts download CSVs, create pivot tables, share files over email; these copies drift outside your retention controls and represent both a compliance gap and a breach risk multiplier. Treating backups as exempt — backup storage is processing, and falls within scope. Claiming "research" without safeguards — indefinite retention under the research exemption, without Article 89 or Section 14(2) safeguards and without restricting other uses, is non-compliant.
Governance and metrics
A retention and deletion policy that exists only as a PDF on a SharePoint site is worth nothing. Effective governance requires measurement.
- 01% of datasets with retention period documented in ROPA. Target: 100%.
- 02% of automated deletion jobs running on schedule. Track failures and resolution time.
- 03Time to fulfil erasure requests. Including backup "beyond use" confirmations.
- 04Number of orphaned exports / working copies discovered per quarter. Trend should fall as governance matures.
- 05Vendor DPA coverage. % of processors with explicit deletion clauses and attestation requirements.
Quick checklist
Inventory every data class participant data touches
From recruitment through reporting. Record in ROPA.
Set defined retention triggers and windows
Tied to last legitimate use, not arbitrary calendar dates.
Choose deletion methods per data class
App-level for cloud platforms; cryptographic erasure for encrypted volumes; NIST sanitisation for physical media.
Apply "beyond use" controls to backups
And disclose this behaviour in your privacy notice and erasure responses.
Document retention in vendor DPAs
Including subprocessor flow-down and deletion attestations.
Automate deletion jobs and audit them
Manual deletion at scale fails. Automation plus monitoring is the only sustainable approach.
Track exports and working copies
Enforce shorter retention than source systems. Re-pull rather than hoard.
Review the policy at least annually
Laws change, processors change, and "just in case" tends to creep back in.
Frequently asked questions
How long should I keep participant data after a research project ends?
There is no single correct answer. The GDPR and POPIA both require that you retain data only as long as necessary for the stated purpose. For most commercial research, contact and recruitment data might be kept 6–12 months after project close, while raw media and transcripts should be deleted or anonymised once analysis and reporting are complete. Consent records often need longer retention to satisfy claims limitation periods. The key requirement is that you define, justify, and document each period.
Can I keep participant data indefinitely for research purposes?
Only with genuine Article 89(1) (GDPR) or Section 14(2) (POPIA) safeguards in place. These include pseudonymisation or anonymisation, separated key files, restricted access, no incompatible re-use, and a DPIA covering long-term retention. You cannot simply label data as "research archives" to avoid deletion obligations.
What counts as "deletion" under GDPR and POPIA if I can't remove data from backups?
Put the data "beyond use." The ICO endorses this approach when immediate deletion from immutable backups is technically infeasible. "Beyond use" means no indexing, no restores except for genuine disaster recovery, strict access controls, and documented overwrite schedules. Disclose this backup behaviour when responding to erasure requests.
Do I need to include retention and deletion terms in my vendor contracts?
Yes. GDPR Article 28(3)(g) requires that processors delete or return all personal data at the end of services and delete existing copies unless law mandates retention. Your DPA should specify deletion timelines, acceptable methods, subprocessor flow-down, and attestation requirements.
What deletion method should I use for encrypted cloud storage?
Cryptographic erasure (destroying encryption keys to render data unrecoverable) is recognised by NIST SP 800-88 Rev.2 as a valid sanitisation technique. It is particularly practical for SSDs and cloud volumes where physical destruction is not an option. Document the key destruction and retain verification records for audit purposes.
How do I handle analyst working copies and CSV exports?
Enforce shorter retention periods for exports than for source systems. Require analysts to re-pull data for fresh analysis rather than hoarding local copies. Include working copies in your retention schedule and audit for compliance. Forgotten exports are one of the most common sources of retention policy drift.
What happens if I exceed my own stated retention periods?
Regulators treat this as a breach of the storage limitation principle, even if the original retention period was reasonable. An EDPB-published enforcement decision confirms that exceeding defined retention windows is actionable. Automated deletion jobs and regular compliance audits are the best defence.
Does POPIA require a specific deletion method?
POPIA Section 14 requires that destruction or deletion happen in a manner that prevents reconstruction of the personal information. It does not prescribe a specific technical method, but the standard is functional: if someone could reassemble the data from what remains, the deletion was insufficient.
Run participant research on a platform that treats deletion as a feature, not an afterthought.
If you're looking for a platform that supports configurable retention, encryption at rest and in transit, role-based access controls, audit logging, and EU or South Africa data residency, book a demo to see how these controls work in WhatsApp-based research workflows.
Book a Demo →
