%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, and regulators actively enforce against over-retention specifically, not just breaches. This guide turns those obligations into a defensible policy for research teams.
A secure retention and deletion policy for participant data 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 that cover backups and vendor-held copies too.
What "participant data" actually covers
Participant data in a research context covers more ground than most people assume: 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 doesn't prescribe specific retention periods, and that's the point. Regulatory guidance is consistent that there are no universal time limits: organisations must set their own periods, justify them, review them periodically, and delete or anonymise data once the original purpose no longer applies.
Article 17 gives individuals the right to erasure (the "right to be forgotten"), obliging controllers to erase personal data without undue delay when certain grounds apply. If data was made public, reasonable steps must be taken to inform other controllers of the erasure request. For backups, immediate secure deletion may not be technically feasible; in those cases, putting data "beyond use" is an accepted interim measure, provided strict access controls and overwrite schedules are in place. GDPR does allow longer retention for scientific research under Article 89(1), but only with appropriate safeguards, and "archiving in the public interest" is not a label that justifies keeping ordinary business records indefinitely.
POPIA Section 14 (South Africa)
POPIA Section 14 prohibits retaining personal information any longer than 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. 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, and record the classification in your Record of Processing Activities. Both GDPR and POPIA expect lifecycle documentation for each dataset.
Map each class to a retention trigger
"End of project" is not a defensible trigger on its own. Tie retention to the last specific action that justifies keeping the data: final report delivery, tax-law expiry for incentives, the claims limitation period for consent records. If you can't articulate why a data class needs to exist at a given point, that's the signal to delete.
Set concrete retention windows
Adapt to sector laws and risk profile rather than defaulting to round numbers if a shorter period is justifiable.
Illustrative defaults for a commercial research project
| Data class | Suggested retention | Notes |
|---|---|---|
| Contact / recruitment info | Project end + 6–12 months | Covers callbacks and complaints; separate panel members into a new lawful-basis context if keeping longer |
| Consent records | 3–6 years (jurisdiction-dependent) | Needed for regulator inquiries; segregate from research content |
| Raw media (voice, video, images) | Through analysis, then delete/anonymise | Apply Article 89(1) or POPIA Section 14(2) safeguards for archiving |
| 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 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; disclose in erasure responses |
Retention choices vary widely based on claims windows and sector obligations. Justify 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 the data was actually deleted when the clock ran out.
Application-level deletion
- Remove rows, documents, and files from production systems.
- Detach any keys or indexes linking pseudonymous codes back to identities.
- Verify the deletion in the ROPA and audit logs.
Cryptographic erasure
- If data is encrypted with field-level or full-disk encryption, destroying the encryption keys renders it unrecoverable.
- Cryptographic erase is recognised as a valid sanitisation technique when implemented correctly.
- Widely accepted in practice as a fast, defensible sanitisation approach for encrypted media.
Media sanitisation for physical devices
- Clear: overwrites or factory resets, appropriate for low-confidentiality reuse.
- Purge: stronger techniques such as cryptographic erase or secure block erase, appropriate for moderate confidentiality.
- Destroy: physical destruction (shredding, melting, disintegration), appropriate for high confidentiality.
Every deletion action needs a paper trail. Sanitisation guidance calls for verification and documentation of every action: sample-based verification of deletion completeness, and certificates of destruction tied to device serial numbers. Auditors specifically look for documentation linking sanitisation actions to individual storage media.
The backup problem
Backups are where most secure retention and deletion policies hit a wall. Modern backup systems often use immutable storage, meaning individual records can't be surgically removed without breaking the integrity of the entire backup set.
The "beyond use" approach
When immediate deletion from backups is technically infeasible, regulatory guidance endorses putting the data "beyond use": no indexing, no access, and no restore except for genuine disaster recovery, strict access controls, and a documented overwrite or expiry schedule. This approach is widely adopted across organisations subject to GDPR. The practical advice: don't promise instant purge from backups in a 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 that the data has been deleted from all active systems, that backup copies exist but are placed beyond use, and that those 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), pseudonymisation or anonymisation, separated key files, restricted access controls, no incompatible re-use, and a DPIA covering long-term retention are all required. The research exemption can't 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
Retention and deletion policies are only as strong as the contracts governing 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.
- 01Explicit deletion or return obligations. Specify timelines, for example within 30 days of service termination.
- 02Deletion method specifications. Don't leave the method ambiguous; specify whether app-level deletion, cryptographic erasure, or physical media sanitisation is required.
- 03Subprocessor flow-down. The same deletion obligations must cascade to every subprocessor: cloud infrastructure, transcription services, analytics tools.
- 04Deletion attestations. Require written confirmation of deletion, with date, method, and scope.
- 05"Beyond use" commitments for backups. If the processor uses immutable backup storage, the agreement should specify isolation controls, access restrictions, and the backup expiry schedule.
Risks and signals regulators care about
Regulators don't just enforce against data breaches; they enforce against over-retention itself. Exceeding your own stated retention windows, even when the original period was defensible, constitutes a breach of the storage limitation principle on its own.
- 01"Just in case" hoarding. Keeping data without a defined purpose or period is the most common finding in regulatory audits of retention practices.
- 02Forgotten exports and working copies. Analysts download CSVs, build pivot tables, and share files over email; these copies drift outside retention controls and multiply both compliance gaps and breach risk.
- 03Treating backups as exempt. Backup storage is processing and falls within scope, not a separate category.
- 04Claiming "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 document on a shared drive is worth nothing. Effective governance requires measurement.
- 01% of datasets with retention period documented in the 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 or working copies discovered per quarter. The trend should fall as governance matures.
- 05Vendor agreement coverage. % of processors with explicit deletion clauses and attestation requirements.
Quick checklist
Inventory every data class participant data touches
From recruitment through reporting. Record it in the ROPA.
Set defined retention triggers and windows
Tied to the last legitimate use, not arbitrary calendar dates.
Choose deletion methods per data class
App-level for cloud platforms, cryptographic erasure for encrypted volumes, physical sanitisation for hardware.
Apply "beyond use" controls to backups
And disclose this behaviour in the privacy notice and erasure responses.
Document retention in vendor agreements
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's no single correct answer. GDPR and POPIA both require retaining data only as long as necessary for the stated purpose. For most commercial research, contact and recruitment data might be kept 6 to 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 defining, justifying, and documenting 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: pseudonymisation or anonymisation, separated key files, restricted access, no incompatible re-use, and a DPIA covering long-term retention. Labelling data as "research archives" doesn't on its own avoid deletion obligations.
What counts as "deletion" under GDPR and POPIA if I can't remove data from backups?
Putting the data "beyond use" is the accepted approach when immediate deletion from immutable backups is technically infeasible. That 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. The agreement 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 a recognised, valid sanitisation technique, particularly practical for SSDs and cloud volumes where physical destruction isn't 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 the 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. Automated deletion jobs and regular compliance audits are the best defence against this drift.
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 doesn't prescribe one specific technical method, but the standard is functional: if the data could be reassembled from what remains, the deletion was insufficient.
Run participant research on a platform that treats deletion as a feature, not an afterthought.
Looking for a platform with 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 →
