In This Article
Overview
Based on our reviews of DPDPA implementations across organisations, certain consent and notice failures appear repeatedly. This article documents the most common failures, explains why they happen, and provides practical fixes.
Consent and notice failures carry significant risk because they affect the fundamental lawfulness of processing. Unlike technical controls that can be remediated quickly, consent failures may require re-obtaining consent from affected data principals.
Notice Implementation Failures
Failure 1: Missing Required Elements
What we find: Privacy notices missing one or more required elements (identity, purpose, rights mechanism, Board complaint process).
Why it happens: Organisations copy generic templates or legacy notices without checking against DPDP requirements.
The fix:
- Create a checklist of all required notice elements
- Review every notice against the checklist
- Have legal/privacy team sign off on completeness
Failure 2: Legal Jargon Overload
What we find: Notices written in dense legal language that data principals cannot understand.
Why it happens: Legal teams draft notices defensively, prioritising legal protection over comprehension.
The fix:
- Apply plain language principles
- Test comprehension with non-legal readers
- Use layered approach: short summary, detailed version available
- Use bullet points and clear headings
Failure 3: Notice Timing Wrong
What we find: Notice provided after data collection (e.g., in post-registration email, not at registration form).
Why it happens: Technical teams implement collection before privacy review; legacy processes not updated.
The fix:
- Map every data collection point
- Ensure notice appears before or at collection
- Include privacy in UX/development review process
Failure 4: Single Language Only
What we find: Notice available only in English when users come from regions with other scheduled languages.
Why it happens: Translation cost and complexity; assumption that English is sufficient.
The fix:
- Assess user demographics and language preferences
- Prioritise languages based on user base
- Implement language selection mechanism
- Ensure translations are accurate (not just machine translation)
Failure 5: Notice Not Updated
What we find: Notice content does not reflect current processing (new purposes, new sharing, changed retention).
Why it happens: No process to trigger notice review when processing changes; legal/privacy not involved in product changes.
The fix:
- Include privacy notice review in change management
- Establish periodic review schedule (at least annual)
- Document change log and version history
Consent Collection Failures
Failure 6: Pre-Ticked Consent Boxes
What we find: Consent checkboxes pre-selected, requiring users to untick to refuse.
Why it happens: Business pressure to maximise consent rates; legacy implementation not updated.
The fix:
- Audit all consent collection points
- Ensure all boxes are unticked by default
- Require affirmative action to consent
- Educate business on legal risks of pre-ticking
Failure 7: Bundled Consent
What we find: Single consent for multiple unrelated purposes (e.g., "I agree to terms, privacy policy, and marketing").
Why it happens: Simplification for user experience; desire to maximise marketing consent.
The fix:
- Unbundle consent for distinct purposes
- Essential processing separate from optional (marketing, analytics)
- Allow granular selection
- Do not deny service for refusing optional consent
Failure 8: Consent Buried in Terms
What we find: Consent obtained through acceptance of lengthy terms and conditions without clear consent mechanism.
Why it happens: Legal conflation of terms acceptance with consent; historical practice.
The fix:
- Separate consent from terms acceptance
- Explicit consent mechanism for personal data processing
- Consent language clearly states what is being consented to
Failure 9: No Consent Records
What we find: No system records of consent given (who, when, what, how).
Why it happens: Technical implementation focused on collection, not record-keeping; assumption that "they must have consented if they're in the system."
The fix:
- Implement consent management system or database
- Record: principal identifier, timestamp, purposes, notice version, collection method
- Retain consent records for duration of processing plus required period
Failure 10: Consent Not Linked to Notice
What we find: Consent records exist but cannot be linked to the notice version in effect at consent.
Why it happens: Consent system and notice versioning not integrated.
The fix:
- Version control all notices
- Link consent records to notice version
- Archive notice versions
Consent Withdrawal Failures
Failure 11: No Withdrawal Mechanism
What we find: No clear way for data principals to withdraw consent.
Why it happens: Focus on consent collection, not withdrawal; business reluctance to facilitate withdrawal.
The fix:
- Implement withdrawal mechanism (self-service preferred)
- Document in privacy notice how to withdraw
- Accept withdrawal through grievance channel at minimum
Failure 12: Withdrawal Harder Than Consent
What we find: Consent collected with one click; withdrawal requires email, phone call, or multiple steps.
Why it happens: Asymmetric design to discourage withdrawal; technical debt.
The fix:
- Make withdrawal as easy as consent
- Self-service option in account settings
- One-click unsubscribe for marketing
Failure 13: Processing Continues After Withdrawal
What we find: Withdrawal recorded but processing continues (marketing emails keep coming, data not deleted).
Why it happens: Manual process not followed; systems not integrated; multiple databases not synchronised.
The fix:
- Automate processing cessation upon withdrawal
- Integrate consent system with processing systems
- Test withdrawal end-to-end
- Audit compliance periodically
Children's Data Failures
Failure 14: No Age Verification
What we find: No mechanism to identify children (under 18) or verify age.
Why it happens: Assumption that service is not for children; complexity of age verification.
The fix:
- Implement age gate or verification mechanism
- Appropriate to service and risk level
- Document approach and rationale
Failure 15: No Parental Consent Process
What we find: Children can be identified but no process to obtain parental consent.
Why it happens: Parental consent is complex to implement; preference to just reject children.
The fix:
- Implement parental consent workflow (if processing children's data)
- Verify parental authority
- Record parental consent
- Or: clearly block service to children
Failure 16: Tracking Children
What we find: Behavioural tracking or targeted advertising applied to users identified as children.
Why it happens: Technical controls not implemented to exclude children; analytics applied universally.
The fix:
- Implement technical controls to exclude children from tracking
- Exclude children from targeted advertising
- Audit analytics and advertising systems
Record-Keeping Failures
Failure 17: Incomplete Consent Records
What we find: Consent records missing key information (timestamp, purposes, collection method).
Why it happens: Minimal implementation; legacy system limitations.
The fix:
- Define required consent record fields
- Update systems to capture all fields
- Validate data quality periodically
Failure 18: Consent Records Not Accessible
What we find: Consent records exist but cannot be retrieved efficiently for rights requests or audit.
Why it happens: Records scattered across systems; no centralised consent management.
The fix:
- Centralise consent records or implement unified query
- Enable search by principal identifier
- Test retrieval for rights request scenarios
Failure 19: No Notice Version Archive
What we find: Previous versions of privacy notices not retained.
Why it happens: Website updates overwrite previous versions; no archival process.
The fix:
- Implement notice versioning
- Archive all notice versions
- Link consent records to notice versions
Remediation Approach
Prioritise by Risk
| Priority | Failure Type | Rationale |
|---|---|---|
| Critical | Pre-ticked boxes, bundled consent, no withdrawal, children tracking | May invalidate consent entirely; high regulatory risk |
| High | Missing notice elements, consent buried in terms, no records | Affects validity of consent; difficult to demonstrate compliance |
| Medium | Legal jargon, single language, withdrawal harder than consent | Affects quality of consent; may not meet "informed" requirement |
| Low | Notice not updated, records not accessible, no version archive | Operational issues; affects audit readiness more than compliance |
Remediation Steps
- Audit: Assess all collection points against requirements
- Prioritise: Address critical and high issues first
- Fix Forward: Implement compliant processes for new collection
- Remediate Existing: Consider re-consent for materially non-compliant consent
- Document: Document remediation and rationale
- Monitor: Ongoing monitoring to prevent recurrence
When consent was materially defective, the safest approach is to re-obtain consent. However, this is a business decision balancing risk against operational impact. Document your decision and rationale.