By Imran M · 28/05/2019 · 7 min read

Data Minimization and Retention for Sensitive Data: A Website Checklist

Website checklist for minimising and retaining high-harm personal data under GDPR Article 5, DPDP section 8 and Rules 6/8, and CCPA section 1798.100.

Working summary: High-harm personal data creates more risk the longer it sits in production, backups, tickets, and analytics warehouses. GDPR Article 5, DPDP section 8 and Rules 6/8, and CCPA section 1798.100 all push the same pattern: collect only what you need, keep it only as long as the purpose requires, then delete or anonymise.

Minimise at the edge: Drop just-in-case fields, tokenise payments, and block pixels from capturing IDs or health text.
Retention schedule: One row per category with purpose, period, deletion method, and owner.
Shorter clocks: KYC images, precise location, health free text, and biometric templates should not linger “because storage is cheap.”
Automate: Purge jobs for databases, warehouses, and object stores; know how backups age out separately.
Notice match: Publish periods that match what the code actually does, including SPI under CCPA 1798.100.

Why minimisation and retention matter for sensitive data

High-harm personal data (health, biometrics used for identification, government IDs, precise location, credentials with access codes, and similar fields) creates more risk the longer it sits in production, backups, tickets, and analytics warehouses. Most major privacy laws push the same basic pattern: collect only what you need, keep it only as long as the purpose requires, then delete or anonymise it.

This checklist is for website and product teams. It draws on GDPR Article 5, ICO guidance on data minimisation and storage limitation, India’s DPDP Act section 8 and Rules on erasure and security logs, and California Civil Code section 1798.100. Regime definitions of “sensitive” differ; see our guides on DPDP, GDPR Article 9, and CCPA sensitive personal information. For finding where the data lives, see OneTrust classification.

What the main laws actually say

Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary for the purposes (data minimisation). Article 5(1)(e) requires that identifiable data is kept no longer than necessary for those purposes (storage limitation), with limited carve-outs for public-interest archiving, research, or statistics under Article 89 safeguards.

The ICO’s minimisation guidance stresses that you identify the minimum you need, do not collect “just in case,” and periodically review and delete what you no longer need. For special category data, the ICO says it is particularly important to collect and retain only the minimum. Storage limitation guidance adds that you justify periods yourself, document them, and anonymise when you no longer need to identify people.

India DPDP Act and Rules 2025

Section 8(7) requires a Data Fiduciary, unless retention is required by law, to erase personal data when consent is withdrawn or as soon as it is reasonable to assume the specified purpose is no longer served, and to cause Processors to erase data made available to them. Section 8(8) deems purpose no longer served in stated inactivity situations. Rule 8 adds class-specific erasure clocks in the Third Schedule (where applicable) and a minimum one-year retention of certain processing logs, traffic data, and related personal data for Seventh Schedule purposes, unless law requires longer. Rule 6 also expects security logs retained for one year for breach investigation unless law requires otherwise.

DPDP does not create a GDPR-style sensitive tier. Treat high-harm fields as a retention and security priority anyway.

CCPA / CPRA

Civil Code section 1798.100 requires notice at collection of categories and purposes, including for sensitive personal information, and of the retention period (or criteria) for each category. A business must not retain personal information or SPI for each disclosed purpose longer than is reasonably necessary for that purpose. Subdivision (c) requires collection, use, retention, and sharing to be reasonably necessary and proportionate to disclosed (or compatible) purposes. CPPA regulations and Enforcement Advisory 2024-01 treat data minimisation as foundational, including when handling consumer requests.

Website checklist: minimisation

1. Purpose register before new fields

For every form field, SDK event, and file upload, write the purpose in one sentence.
Reject fields that do not serve that purpose (for example health questions on a newsletter signup).
Split optional from mandatory. Never mark SPI or special category fields required unless the product cannot work without them.

2. Collect less at the edge

Prefer progressive profiling over one long intake form.
Use derived flags (“accessibility preference: yes”) instead of storing diagnosis text when a yes/no meets the need.
Tokenise payment credentials; do not store raw card numbers plus CVV in application databases.
Truncate precise geolocation to a coarser granularity when the feature only needs city or region, and document why any finer precision is necessary.

3. Stop silent copies

Block marketing pixels and session replay from capturing password, payment, government ID, or health fields.
Strip SPI from support ticket mirrors and chat transcripts where possible, or route those conversations to a restricted queue.
Disable full production database clones for engineering unless fields are masked or tokenised.

4. Vendor and processor scope

List which vendors receive which categories.
Contract for purpose limits and deletion or return at end of service (DPDP section 8; CCPA section 1798.100(d); GDPR Article 28).
Turn off unused SaaS fields and export jobs that pull SPI into BI tools “for later.”

Website checklist: retention

5. Write a retention schedule

One row per data category (account profile, order records, KYC images, support attachments, analytics events, security logs).
Columns: purpose, lawful basis or DPDP ground, retention period or criteria, deletion or anonymisation method, system owner.
ICO audit toolkit guidance: own the schedule, review it regularly, and document post-retention actions (delete, anonymise, or archive with safeguards).

6. Set shorter clocks for high-harm data

KYC images and government ID scans: retain only while onboarding or legal hold requires; purge from active stores afterward.
Precise location histories: keep rolling windows measured in days or weeks unless a disclosed purpose needs more.
Health or accessibility free text: keep only while the request is open, then summarise without clinical detail if you must keep a record.
Biometric templates used for login: delete on account closure and on withdrawal of the relevant consent or condition.

7. Automate deletion and anonymisation

Job that hard-deletes or cryptographically shreds expired rows in primary databases.
Separate process for object storage, search indexes, CDNs, and warehouse tables.
Anonymise analytics where you only need trends; do not keep re-identifiable event streams “because BigQuery is cheap.”
Respect legal holds: pause deletion with a documented override, then resume.

8. Backups and logs

Know backup retention separately from application retention; plan how expired SPI ages out of backup cycles.
Under DPDP Rule 6 / Rule 8 patterns, plan for roughly one year of security and processing logs where those rules apply to you, without using that floor as an excuse to keep full customer SPI forever in the same store.
Separate security logs (access events) from content stores (the sensitive payload).

9. Erasure and withdrawal paths

Wire account deletion and DSAR erasure to the same schedule engines.
On consent withdrawal (DPDP section 8(7); GDPR Articles 7(3) and 17 where applicable), stop non-essential processing and erase when law does not require retention.
Confirm Processors and ad platforms receive the same instruction.

10. Notice that matches reality

CCPA: publish retention periods or criteria per category, including SPI, at or before collection (section 1798.100(a)(3)).
GDPR: privacy notice should reflect actual periods (Articles 13 and 14 transparency).
DPDP: notice and purpose texts should match what your schedule and code do.
If engineering changes a retention job, update the notice in the same release.

Quarterly review prompts

Which new forms or SDKs shipped without a purpose row?
Which SPI categories exceeded their schedule without a legal-hold ticket?
Which vendors still hold exports after contract end?
Which warehouse tables still join raw government IDs to marketing segments?

Suggested rollout order

Inventory high-harm fields (reuse discovery tools if you have them).
Draft the retention schedule with legal and security.
Remove unnecessary form fields and pixel captures.
Implement automated purge for the top three SPI stores.
Align privacy notice text.
Add monitoring for schedule breaches.

Sources

Regulation (EU) 2016/679, Article 5(1)(c) and (e) (data minimisation; storage limitation).
ICO: Principle (c) Data minimisation; Principle (e) Storage limitation; Retention audit toolkit pages.
Digital Personal Data Protection Act, 2023, section 8(5), 8(7), 8(8); Digital Personal Data Protection Rules, 2025, Rules 6 and 8 and related schedules.
California Civil Code section 1798.100 (notice, retention, reasonably necessary and proportionate processing); CPPA Enforcement Advisory No. 2024-01 on data minimization.

Disclaimer

This article was prepared by Imran using publicly available information. It is for general education only and is not legal advice. Do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, sensitive-data controls, breach response, or other privacy and data-protection measures. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 24 September 2026