A practical guide to GDPR data minimization under Article 5(1)(c) — what 'adequate, relevant, and limited' means, how DPAs enforce it, and how to automate compliance across SaaS and cloud.
.webp)
GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." This is the data minimization principle — a legally binding obligation, not a best practice. Four things to know: 1. Minimization applies at collection AND at retention — keeping data too long violates Article 5(1)(e), which is connected. 2. DPAs have fined organizations specifically for retaining more data than necessary — not just for breaches. 3. "Necessary" is judged against your stated purpose — data that was legitimate to collect becomes non-compliant once the purpose ends. 4. Strac automates discovery, redaction, and deletion across Salesforce, Zendesk, Slack, S3, and 50+ other systems to enforce minimization at scale.
GDPR data minimization is one of the six data processing principles under Article 5. It requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."
That three-part standard — adequate, relevant, limited — applies to everything: what you collect at the point of entry, what you store in your systems, and how long you retain it. Minimization is not a one-time audit. It is an ongoing obligation that applies for the entire lifecycle of every personal data record.
This post covers what the principle means in practice, how EU data protection authorities have enforced it, what it requires operationally, and how Strac automates compliance across the systems where personal data accumulates.
Article 5(1)(c) states that personal data shall be:
"adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ('data minimisation')"
Each word carries legal weight:
Adequate means the data you collect is sufficient to achieve the purpose. If you need an email to send a receipt, collecting the email is adequate. Collecting nothing would fail adequacy. This sets a floor — don't collect so little that you can't fulfill your service obligation.
Relevant means the data directly relates to the stated purpose. A customer's phone number is relevant if you need to contact them for service. It is not relevant if you are collecting it for a newsletter with no stated phone-based communication.
Limited means not excessive beyond what the purpose requires. This is where most organizations have exposure: they collect data that is relevant in some sense but broader in scope than necessary — full date of birth instead of age range, full home address instead of city, Social Security Number when only an employee ID was needed.
The three criteria must all be satisfied simultaneously for each data element collected.
Article 5(1)(c) on minimization is closely linked to Article 5(1)(e) on storage limitation:
"kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed"
The two principles work together: minimization limits what you collect; storage limitation limits how long you keep it. DPAs enforce both. Data that was compliant to collect becomes non-compliant when retained beyond the period necessary for the purpose.
What this requires operationally: - Define retention periods for each category of personal data - Document those periods in your Record of Processing Activities (RoPA) and privacy notice - Actually enforce deletion when retention periods expire - Apply the same rules to processors and sub-processors via Article 28 contracts
GDPR data minimization violations have been enforced as standalone violations — not just bundled with breach penalties. Key enforcement patterns:
The enforcement signal is clear: DPAs treat retention failures as minimization violations. "We collected it lawfully" is not a defense for retaining it beyond the stated purpose.
The practical question is: which data types create the most minimization exposure in a typical B2B or B2C organization?
Support ticket example: A customer provides their passport number in a support ticket to verify their identity for an account recovery request. The legitimate purpose — identity verification — is fulfilled the moment identity is confirmed. GDPR data minimization requires the passport number to be deleted at that point. Retaining it in the ticket archive indefinitely is a minimization and storage limitation violation.
Marketing database example: A company collected email addresses and job titles for a conference. Post-conference, contacts who did not respond to follow-up emails within 12 months are no longer engaged. Retaining them in the marketing database beyond the point of legitimate interest expiry violates Article 5(1)(c).
CRM notes example: A sales representative pastes a prospect's income bracket and personal relationship details into a CRM note during a discovery call. This data was not necessary for the commercial purpose of the CRM system. Collecting it in the first place violates the limitation criterion.
If you are also subject to CPRA, HIPAA, or PCI DSS, the minimization obligations overlap and reinforce each other:
CPRA data minimization → | HIPAA DLP → | PCI DLP →
The gap between GDPR data minimization policy and actual compliance is almost always an enforcement gap — organizations know what the principle requires, but lack tooling to discover where excess data lives and remove it automatically.
Strac closes that gap across three layers:
1. Data discovery across SaaS and cloud (DSPM)
Strac scans Salesforce, Zendesk, Google Drive, S3, Slack, GitHub, Microsoft 365, and 50+ other integrations via API — building a live map of where personal data lives, what type it is, and when it was last accessed. For GDPR compliance, this inventory is the foundation of your RoPA and the starting point for any minimization program.
2. Inline redaction
When Strac identifies personal data that should be removed — an SSN in a closed support ticket, a passport number in a 3-year-old email thread, health data in an S3 export — it redacts it inline, replacing the sensitive value with a token. The surrounding record is preserved; the PI is removed. Strac is the only DLP that also processes images and scanned documents via OCR, so ID document photos do not escape detection.
3. Automated deletion
For records and files past their retention period, Strac triggers deletion workflows tied to your defined retention schedule. Data past its purpose is deleted automatically — no manual review, no gaps when staff are on leave.
See all integrations → | GDPR-relevant compliance pages → | Book a demo →
GDPR data minimization is the requirement under Article 5(1)(c) that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." It is one of the six core data processing principles in GDPR and applies to collection, retention, and use of all personal data of EU residents.
Adequate means sufficient to fulfill the stated purpose. Relevant means directly connected to that purpose. Limited means not broader in scope than necessary for that purpose. All three criteria must be met simultaneously for each data element. Most violations involve the "limited" criterion — organizations collect or retain data that is arguably relevant but broader than strictly necessary.
They are two separate principles — Article 5(1)(c) for minimization and Article 5(1)(e) for storage limitation — but operationally linked. Minimization determines what you collect; storage limitation determines how long you keep it. DPAs have enforced both in the same cases, particularly where organizations retained data well past the point where the original purpose was fulfilled.
Retaining customer support tickets containing passport numbers or SSNs for years after the support issue was resolved is a common violation. The data was legitimately collected for identity verification; retaining it indefinitely violates both Article 5(1)(c) and Article 5(1)(e). DPAs have fined organizations specifically for retention failures of this type.
Fines can reach 2% of global annual turnover for violations of the Article 5 principles (under Article 83(4)) or up to 4% for the most serious infringements. In practice, DPAs have levied fines in the €50K–€1M range for standalone minimization violations, with higher fines when minimization failures contributed to a data breach.
Yes. Processors must comply with Article 5 principles through Article 28 contracts. A data controller's minimization obligations flow to processors — if your controller instructs a processor to retain data, and that retention violates Article 5(1)(e), both parties bear liability. Processor contracts must include defined retention periods and deletion obligations.
GDPR uses a three-part test (adequate, relevant, limited). CPRA uses a proportionality standard (reasonably necessary and proportionate). GDPR applies to all personal data; CPRA applies to California consumers and adds specific controls for sensitive PI. GDPR has a formal regulatory enforcement structure with DPAs in each EU member state; CPRA is enforced by the California Privacy Protection Agency. Both require the same operational outcome: delete data when the purpose ends.
.avif){kind=icon}
.gif)
