DMA & Google: Mandatory Consent, Technical Audit & Compliance

Audit & Compliance : DMA & Google (EN)

The DMA and the Evolution of Digital Consent

The Digital Markets Act (DMA), a cornerstone of European digital regulation, profoundly redefines the obligations of 'gatekeepers' such as Google. Its objective is to ensure fair and contestable digital markets by tackling anti-competitive practices and strengthening user sovereignty over their data. For Google, this regulation translates into increased consent requirements, well beyond the standards established by GDPR or ePrivacy, particularly concerning the combination and use of personal data across its multiple services.

Scope of the DMA and Google's Status as a 'Gatekeeper'

Google has been designated as a gatekeeper for several of its key services, including Google Search, Chrome, Android, Google Maps, Google Play, Shopping, and YouTube, as well as for its advertising operating system. This designation implies the strict application of the obligations under Articles 5 and 6 of the DMA. Article 5(2) is particularly relevant: it prohibits gatekeepers from combining personal data from their core platform services with data from other services offered by the gatekeeper or with personal data from third-party services, unless the user has given explicit consent. This prohibition also extends to the use of personal data collected via third-party services for the gatekeeper's core platform services. The granularity and revocability of consent become technical and legal imperatives.

Impact on Google Services and Personal Data Processing

The DMA's impact on Google services is systemic. Companies using Google Analytics, Google Ads, Google Tag Manager (GTM), or any other Google service that collects user data must completely review their consent mechanisms. Consent must not only be free, specific, informed, and unambiguous (in accordance with GDPR) but also explicit for each purpose of data combination by Google. This means that generic consent banners or pre-checked options are now insufficient. Users must have granular control over how their data is used and combined across different Google services (e.g., search data with YouTube data, or location data with advertising data). Proof of this consent must be retained and accessible to regulatory authorities.

Technical Architecture of Consent: Implementation and Validation

DMA compliance requires a technical overhaul of consent management systems. It's no longer just about displaying a banner, but about orchestrating script loading and data collection based on the user's precise choices. Integrating a robust Consent Management Platform (CMP) and implementing prior blocking techniques are crucial.

Integration of a TCF v2.2 and DMA-Compliant CMP

An IAB Transparency and Consent Framework (TCF) v2.2 certified CMP is a technical prerequisite. It must allow for the collection of granular consent for each purpose and each vendor, including Google. TCF v2.2 provides a consent signal (TC String) that vendors can read. However, the DMA imposes additional requirements: the CMP must avoid 'dark patterns' (deceptive practices encouraging consent), offer an equivalent choice between accepting and refusing, and ensure easy revocability. Google Consent Mode v2 is an essential technical mechanism for communicating consent status to Google, allowing Google services to adjust their data collection behavior (basic or advanced mode) based on user consent, even in the absence of cookies.

Prior Blocking of Trackers: Strategies and Implementation

The principle of prior blocking is non-negotiable: no non-essential cookie or tracker must be placed before obtaining the user's explicit consent. This applies to all Google scripts (Analytics, Ads, etc.).

Implementation Strategies:

1. GTM with Consent Mode v2 and Custom Templates: Use GTM to manage conditional tag loading. Google tags must be configured to respect Consent Mode. For third-party tags or custom scripts, custom tag templates can be developed to integrate consent logic.
2. data-consent-category Attributes and JavaScript: Modify <script> tags so they do not execute by default.

GTM Blocking Example (Custom HTML Tag):

<script type="text/plain" data-consent-category="analytics">
  // Your Google Analytics code or other tracking script
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
  ga('create', 'UA-XXXXX-Y', 'auto');
  ga('send', 'pageview');
</script>

A client-side JavaScript script, triggered by the CMP after consent, will look for these tags and change their type to text/javascript to execute them.

JS DOM Blocking Example (for non-GTM scripts):

document.addEventListener('DOMContentLoaded', function() {
  const scriptsToBlock = document.querySelectorAll('script[data-consent-category]');
  scriptsToBlock.forEach(script => {
    // Initially, block execution
    script.setAttribute('type', 'text/plain');
  });

  // Function called by the CMP after consent
  window.executeScriptsByConsent = function(consentCategories) {
    scriptsToBlock.forEach(script => {
      const category = script.getAttribute('data-consent-category');
      if (consentCategories.includes(category) && script.getAttribute('type') === 'text/plain') {
        const newScript = document.createElement('script');
        // Copy all attributes from the old script
        Array.from(script.attributes).forEach(attr => {
          newScript.setAttribute(attr.name, attr.value);
        });
        newScript.setAttribute('type', 'text/javascript'); // Allow execution
        newScript.innerHTML = script.innerHTML; // Copy content if inline
        script.parentNode.replaceChild(newScript, script);
      }
    });
  };

  // Example call after the CMP has determined consent
  // if (userHasGivenConsentForAnalytics) {
  //   window.executeScriptsByConsent(['analytics', 'marketing']);
  // }
});

In-Depth Technical Audit: Methodology and Tools

A rigorous audit is essential to validate technical compliance. It must simulate user journeys and verify tracker behavior in different consent scenarios.

Analysis of Data Flows and Network Calls

The main tool is the 'Network' panel of your browser's developer tools (Chrome DevTools, Firefox Developer Tools). It allows you to inspect all HTTP/HTTPS requests made by the page. You need to check:

• Initial Requests: No requests to Google domains (google-analytics.com, googletagmanager.com, doubleclick.net, etc.) should be made before consent for the corresponding categories.
• Cookies and Local Storage: The 'Application' panel allows you to view cookies, local storage (localStorage), and session storage (sessionStorage). Verify that no non-essential cookies are placed before consent. Google cookies (_ga, _gid, _fbc, _fbp, etc.) must be absent.
• Request Parameters: For Google Analytics requests, check for the presence of the gcs (Google Consent State) and gcu (Google Consent Update) parameters, which reflect the consent status.

User Scenario Simulation and Resilience Tests

It is crucial to test all consent scenarios:

1. Total Refusal: The user refuses all non-essential categories. Verify that no trackers are activated and no cookies are placed.
2. Total Acceptance: The user accepts everything. Verify that all expected trackers are activated and cookies are placed.
3. Granular Choice: The user accepts some categories and refuses others. Verify that only consented trackers are active.
4. No Choice (Banner Ignored): The default behavior must be refusal.
5. Consent Revocation: After accepting, the user revokes their consent. Verify that trackers are deactivated and cookies are deleted.
6. Consent Persistence: The user's choice must be remembered on subsequent visits.

Audit Steps with Chrome DevTools:

1. Open your site in a private browsing window.
2. Open DevTools (F12 or Ctrl+Shift+I).
3. Go to the 'Network' tab. Check 'Disable cache' and filter by domain (e.g., google-analytics.com, doubleclick.net).
4. Refresh the page. Before any interaction with the CMP, no requests to the filtered domains should appear.
5. Go to the 'Application' tab. Under 'Storage', check 'Cookies' and 'Local Storage'. No non-essential Google cookies should be present.
6. Interact with the CMP: refuse everything. Recheck the 'Network' and 'Application' tabs. The status should remain unchanged.
7. Refresh the page. The refusal must persist.
8. Interact with the CMP: accept everything. Check the 'Network' tab: Google requests should now appear. Check the 'Application' tab: Google cookies should be present.
9. Repeat for granular choice scenarios.

Consent Proof Management and Reporting

Compliance does not stop at technical implementation; it also includes the ability to prove consent in the event of an audit or complaint.

Secure Storage of Consent Proofs

Each consent interaction must be recorded securely and unalterably. The minimum information to store includes:

• User ID: A unique identifier (pseudonymized if possible) to link consent to a user.
• Timestamp: Precise date and time of the consent/refusal action.
• Consent Status: Specific choices for each purpose and each vendor (e.g., Analytics: accepted, Advertising: refused).
• Privacy Policy Version: The version of the policy in effect at the time of consent.
• CMP Version: The version of the Consent Management Platform used.
• Technical Proof: The TC String (for TCF) or a hash of the choices.
• IP Address: For evidentiary purposes, although this should be handled with caution and pseudonymized.

This data must be stored in a secure database, with audit trail mechanisms to ensure the integrity and traceability of modifications.

Example JSON Structure for Consent Proof:

{
  "consentId": "uuid-v4-example-12345",
  "userId": "hashed-user-id-abcde",
  "timestamp": "2026-08-09T14:30:00Z",
  "consentStatus": {
    "analytics": "accepted",
    "marketing": "rejected",
    "personalization": "accepted"
  },
  "vendors": {
    "google": {
      "analytics": "accepted",
      "ads": "rejected"
    },
    "facebook": {
      "pixel": "rejected"
    }
  },
  "policyVersion": "1.2",
  "cmpVersion": "3.1.0",
  "tcString": "CPq...",
  "ipAddressHash": "sha256-hashed-ip-address"
}

Reporting and Compliance with Regulatory Requirements

Gatekeepers and the companies that use them must be prepared to provide detailed reports to regulatory authorities (such as the CNIL in France) proving their compliance. These reports must include:

• Statistics on consent/refusal rates.
• Technical proofs of collected consents.
• Documentation of consent management processes.
• Internal and external audits performed.

The ability to generate these reports quickly and reliably is a key indicator of compliance maturity. Business Intelligence (BI) tools can be integrated with the consent database to facilitate this task.

Comparative Table of CNIL Sanctions for Cookie Non-Compliance

CNIL sanctions highlight the seriousness of non-compliance, even before the full entry into force of the DMA. The DMA provides for even heavier fines, potentially reaching 10% of the company's annual worldwide turnover, and up to 20% in case of repeat infringements.

These examples illustrate the vigilance of authorities and the need for impeccable compliance, both technically and in terms of user experience. The DMA reinforces this trend, demanding unprecedented transparency and user control.