GDPR enforcement is no longer dominated by a small number of headline fines against technology giants. The pattern in 2025 and into 2026 has shifted toward broader enforcement activity, more national DPA engagement, and a clear concentration on failures that product teams produce directly: consent mechanisms, data subject rights responses, and inadequate records of processing.
CMS Law's GDPR Enforcement Tracker Report recorded roughly €6.11 billion in cumulative GDPR fines by its 1 March 2026 cut-off, across 2,685 recorded fines. The trend in recent enforcement cycles is not just a few headline penalties but broader activity across sectors and sizes. DPAs are also coordinating enforcement priorities through the EDPB's Coordinated Enforcement Framework: the 2026 action focuses on transparency and information obligations under Articles 12, 13, and 14 GDPR.
WHERE_ENFORCEMENT_IS_CONCENTRATING
The enforcement activity most relevant to product teams falls into four categories. Cookie consent mechanisms remain a high-volume target across multiple DPAs. Inadequate responses to data subject requests — late, incomplete, or incorrectly scoped — continue to generate both complaints and fines. Transparency and information duties are receiving coordinated attention in 2026. Unlawful international data transfers, particularly following scrutiny on standard contractual clauses and the implementation of the EU-US Data Privacy Framework, remain a live risk for products using US-based cloud services and analytics tools.
The cookie consent failures that generate enforcement decisions are not usually technical failures in the consent management platform. They are design decisions: pre-ticked boxes, consent bundled with terms of service acceptance, no genuine reject option at the same level as the accept option, and dark patterns that make the non-consent path harder to complete than the consent path. Those are product decisions made in sprint planning and design review, not configuration errors in a third-party platform.
"Most GDPR fines trace back to a product decision made in a sprint meeting."
CONSENT_MECHANISM_REQUIREMENTS
The EDPB's guidelines on consent and the combined output of national DPA decisions create a reasonably clear picture of what a lawful consent mechanism requires for cookies and tracking. The core requirements are: a clear description of each purpose for which consent is sought, granular choices at the purpose level (not just accept all or reject all), a genuine reject path that is as easy to complete as the accept path, and a mechanism to withdraw consent at any time that is as easy as giving it.
The reject path requirement is where most consent banners fail enforcement review. Common failure modes include: no reject button at the first layer of the banner (requiring the user to navigate to settings to reject), a "reject" button that is styled to be visually less prominent than the accept button, reject options that require individually unchecking boxes while accept all is a single click, and consent withdrawal buried in settings menus at a depth that makes it disproportionately difficult to reach.
Legitimate interest as a basis for analytics and advertising tracking has been largely rejected by DPA decisions across multiple Member States. If your product relies on legitimate interest for any non-essential tracking, the assessment of that reliance should be reviewed in light of current enforcement decisions, not the 2018-era guidance that may have informed the original implementation.
- Audit your consent banner against the equal-prominence requirement: the reject path should require the same number of clicks and interactions as the accept path.
- Review every legitimate interest assessment that covers tracking or profiling activity. DPA decisions have consistently found legitimate interest inapplicable in these contexts.
- Test consent withdrawal — find it in your product interface without knowing in advance where it is. If it takes more than two interactions, it likely does not meet the "as easy as giving consent" standard.
- Document the consent mechanism design decisions, including the rejection of dark patterns, so the rationale is on record if a complaint investigation asks how the design was arrived at.
DATA_SUBJECT_RIGHTS_RESPONSE_GAPS
Data subject access requests (DSARs) are the operational side of GDPR that most product organisations handle worst. The compliance picture improved significantly in 2019 and 2020 as organisations built initial DSAR processes. It has degraded since then in many organisations as the processes were not maintained alongside product and data architecture changes.
The common gaps that surface in enforcement actions are: data subject requests that are not responded to within the one-month statutory period (or the extended three-month period where extension is justified and communicated); responses that are incomplete because the response process does not cover all data stores that contain personal data; identity verification requirements that are so burdensome they effectively deny the right; and responses that confuse the access right with data portability rights and provide the wrong format or scope of information.
The one-month clock starts when the request is received, not when it is processed by whoever handles it. Requests received via generic customer service channels, social media, or product feedback routes are still valid DSARs if they can be reasonably understood as exercising the right of access. Building a clear intake path for DSARs and ensuring all customer-facing teams know how to recognise and route them correctly is a prerequisite for consistent compliance.
- Run a DSAR process audit against your current data architecture — not the architecture that existed when the process was first built. Data stores and processing activities change; the response process needs to cover the current state.
- Map every customer-facing channel and confirm that requests arriving via those channels are routed to the DSAR process, not handled as general customer service queries.
- Review identity verification requirements against the principle of proportionality. Verification should confirm identity, not create a barrier that discourages exercise of the right.
- Track response time against the statutory deadline for every request. Late responses are reportable in complaint investigations and demonstrate systematic process failure.
RECORDS_OF_PROCESSING_AND_AUDIT_READINESS
Article 30 records of processing activities are required for most organisations and are routinely requested in DPA investigations. Records that were created at initial GDPR implementation and not maintained since are among the most common deficiencies found in enforcement investigations — not because the underlying processing is unlawful, but because the documentation no longer reflects reality.
The record needs to cover: the purposes of processing, the categories of data subjects and personal data, recipients, transfers to third countries with their safeguards, and where possible the retention periods. For organisations with complex data ecosystems, keeping this accurate requires a defined process for updating the record when new processing activities are introduced or existing ones change. That process typically needs to be built into the product development and procurement workflows, not maintained as a separate compliance exercise.
DPA investigations that find outdated or incomplete Article 30 records tend to expand their scope, because the outdated record raises questions about what else in the compliance programme has not kept pace with changes to the business. Maintaining accurate records is not just a compliance obligation in itself — it is a signal of overall programme quality that affects how investigations proceed.