A customer clicks "stop marketing" in your app. Your system logs the request. Seven months later, they're still getting promotional push notifications. When they call support, the agent tells them it can't be disabled, even though your engineering team later proves it can be.
This isn't a hypothetical scenario. The Italian Data Protection Authority fined BBVA EUR 5,508,000 for exactly this failure. The customer objected through the app, contacted Customer Service, and received at least ten more promotional messages over seven months. BBVA's defense, that the customer should have used a specific email address listed in the privacy policy, didn't persuade the regulator.
Why These Mistakes Keep Happening
Most organizations treat data subject rights as a compliance checkbox rather than a technical integration challenge. You've documented procedures in your privacy policy. You've trained your support team on GDPR basics. But when a customer exercises their Article 21 right to object, the request enters a complex ecosystem: CRM platforms, marketing automation tools, mobile app backends, email service providers, and customer service ticketing systems.
Each integration point is a potential failure mode. The Italian DPA's decision against BBVA cited deficiencies in both technical and organizational measures, not just one broken sync job, but a systemic inability to honor a straightforward request across channels.
Mistake 1: Requiring Requests Through Your Preferred Channel
Why it happens: Your privacy policy specifies a dedicated email address or web form for data subject requests. You've built workflows around that intake method. When customers use other channels, app settings, live chat, phone calls, those requests fall outside your documented process.
The consequence: BBVA argued the customer should have used the email addresses in the privacy policy. The Italian DPA rejected this defense entirely. Article 12 GDPR requires you to "facilitate the exercise" of data subject rights. If a customer submits a valid objection through any channel you operate, you must honor it. Directing them to start over through your preferred method violates the regulation.
The fix: Map every customer interaction channel you operate, mobile apps, web portals, phone support, live chat, email, physical branches. For each channel, define how a data subject request reaches your central intake queue. Consider a team using Zendesk for support tickets: configure triggers that tag messages containing keywords like "delete my data" or "stop marketing" and route them to your privacy operations team. Your intake system should accept requests from any channel, not just the one you find convenient.
Mistake 2: Treating System Sync Failures as IT Problems, Not Compliance Risks
Why it happens: Your customer submits an objection. Your primary database records it correctly. But the marketing automation platform doesn't receive the update because a scheduled sync job failed, or because the integration uses batch processing with a 24-hour delay.
The consequence: BBVA's technical team correctly recorded the customer's objection, but a synchronization failure prevented the CRM unit from receiving it. Seven months of continued marketing followed. The Italian DPA found this violated Article 24's requirement for appropriate technical and organizational measures. When your systems can't reliably propagate consent and objection data, you're not just facing an operational issue, you're in breach of your controller obligations.
The fix: Implement real-time propagation for data subject rights changes, not batch updates. When a customer objects to marketing, that signal should reach every system capable of contacting them within minutes, not days. Build monitoring that alerts your privacy team when synchronization fails. If you're using a Customer Data Platform or consent management tool, configure it to push updates immediately to downstream systems. Test the full propagation path quarterly: submit a test objection and verify it reaches your email platform, SMS gateway, push notification service, and any third-party marketing tools within your defined SLA.
Mistake 3: Giving Customer Service Incorrect Information About Technical Capabilities
Why it happens: Your support agents follow scripts and knowledge base articles. When a customer asks about disabling specific types of communication, the agent checks the documentation and reports what it says. But the documentation doesn't reflect actual system capabilities, or it was written before a recent platform migration.
The consequence: BBVA's Customer Service told the customer that promotional push notifications couldn't be disabled through the app. The Italian DPA noted that BBVA later demonstrated these notifications could indeed be stopped. Providing incorrect information about data subject rights capabilities compounds the original failure and suggests inadequate organizational measures under Article 24.
The fix: Conduct quarterly audits where your privacy team tests every data subject rights claim in your customer-facing documentation. Can customers actually control the data types you say they can control? Do the opt-out mechanisms you describe actually work? When you implement new communication channels, WhatsApp business messaging, in-app notifications, SMS campaigns, update your support documentation and train agents before launch. Consider implementing an escalation path: if a customer insists they should be able to control something your agent says isn't possible, route it to a privacy specialist who can verify the technical reality.
Mistake 4: Assuming One Objection Mechanism Covers All Communication Types
Why it happens: You've built a preference center where customers can opt out of "marketing communications." You interpret that broadly to include email, SMS, and push notifications. But your mobile app team treats in-app promotional messages as part of the user experience, not marketing, so they're excluded from the preference center's scope.
The consequence: When the BBVA customer objected through the app and contacted Customer Service, they expected all promotional communications to stop. The bank's internal systems apparently distinguished between different types of marketing, allowing some messages to continue. The Italian DPA's decision doesn't accept these internal categorizations as a defense, if a customer objects to direct marketing under Article 21, you must stop all promotional processing.
The fix: Inventory every communication channel that could be considered direct marketing: transactional emails with promotional content, in-app banners, push notifications about new products, SMS offers, phone calls from sales teams, physical mail. Map each channel to the objection mechanisms you offer. When a customer exercises their Article 21 right to object, that objection must suppress all direct marketing across all channels. If you maintain separate consent for different communication types, make the distinctions clear and give customers granular control. But a blanket objection to marketing must have blanket effect.
Mistake 5: Treating Prior Infringements as Isolated Incidents
Why it happens: Your organization received a warning or a fine for a data protection issue two years ago. You addressed that specific problem, documented the remediation, and moved on. You don't connect that incident to your current data subject rights infrastructure.
The consequence: The Italian DPA considered BBVA's previous relevant infringement as an aggravating factor when determining the EUR 5,508,000 fine. Regulators expect you to learn from past failures and implement systemic improvements. If you continue demonstrating similar deficiencies, inadequate technical measures, poor cross-system coordination, failure to honor data subject rights, each subsequent infringement will be treated more severely.
The fix: After any data protection incident or regulatory finding, conduct a root cause analysis that looks beyond the specific failure. If you failed to honor an objection because of a system sync issue, don't just fix that one integration, audit all your data flows for similar risks. Document the systemic improvements you've made and how they prevent related failures. When the Italian DPA ordered BBVA to inform them of corrective measures within 30 days, they weren't asking for a patch to one system, they wanted evidence of comprehensive technical and organizational improvements.
Prevention Checklist
Use this checklist quarterly to audit your data subject rights infrastructure:
- Test data subject request intake from every customer interaction channel you operate
- Verify real-time propagation of consent and objection changes to all downstream systems
- Audit customer service scripts and documentation against actual technical capabilities
- Confirm that a blanket objection to marketing suppresses all promotional communications
- Review monitoring alerts for data subject rights processing failures in the past 90 days
- Document the maximum time between request receipt and system-wide implementation
- Verify that third-party processors receive objection and consent updates within your SLA
- Test the full technical path: submit a test objection and confirm it reaches every system
- Review any prior data protection findings and confirm systemic improvements remain in place
- Validate that your preference center reflects all communication channels currently in use
The Italian DPA's decision against BBVA makes clear that Article 12's requirement to "facilitate the exercise" of data subject rights isn't satisfied by documenting procedures. Your technical and organizational measures must reliably honor requests regardless of which channel customers use, and system failures don't excuse continued violations. Seven months of promotional messages after a customer objects isn't an IT problem, it's a compliance failure that regulators will penalize accordingly.
