DMA compliance program and monitoring

Start with the Commission designation decisions and the current list of designated core platform services. The compliance register should be organised by gatekeeper, core platform service, DMA case reference, applicable Article 5, 6 or 7 obligation, and the product surface or data flow that implements the measure.

For each service-obligation pair, keep a positive compliance statement only where the evidence supports it. If an obligation is said not to apply by nature to a particular service, record the legal reason separately; the Article 11 template treats that as a specific explanation, not as a general exception.

Article 11 requires a report describing, in a detailed and transparent manner, the measures implemented to ensure compliance, plus a non-confidential summary. The Commission template makes that evidence concrete: it asks for the pre-measure situation, implementation timing, product and geographic scope, technical or engineering changes, customer-experience changes, remuneration and terms changes, consultation records, alternatives assessed, impact testing, indicators, and internal monitoring tools.

The compliance program should therefore collect evidence continuously, not only near the reporting deadline. Product teams should attach engineering tickets, API documentation, data-flow descriptions, screenshots, recorded demos for user journeys, terms updates, experiment methodologies, survey results, and metric definitions to the same control record that supports the Article 11 annex.

Article 28 requires an independent compliance function with sufficient authority, stature, resources, and access to the management body. The program should make that independence visible in records: reporting line, budget, staff, conflicts controls, escalation rights, and direct access for the head of compliance.

The compliance function should not be limited to annual attestation. It should organise, monitor, and supervise compliance measures; inform and advise management and employees; monitor commitments where applicable; and cooperate with the Commission. Management-body review should be captured through approved policies, meeting dates, participants, agendas, minutes, and replies to compliance-function risk reports.

A DMA control gate should run before launch when a change touches a designated core platform service, a business-user route to end users, end-user choice, ranking, default settings, interoperability, data access, advertising, app distribution, consent, remuneration flows, terms, APIs, operating-system functionality, or customer journeys documented in an Article 11 annex.

The gate should ask whether the change implements a compliance measure, modifies a reported measure, weakens an existing measure, creates a new access procedure, or changes an effectiveness indicator. A release can proceed only when the owner has updated the obligation mapping, monitoring metric, evidence record, user-facing material, and Article 11 delta log.

The grounded cadence has three layers: Article 11 reporting is updated at least annually, Article 28 management-body strategies and policies are reviewed at least once a year, and ongoing monitoring should occur whenever new compliance measures are elaborated, put in place, or affected by events. The program should avoid inventing a single universal monthly or quarterly cadence unless the company has chosen that internally.

Audit records should show how effectiveness was assessed. The Article 11 template asks whether internal or external audits or assessment projects were carried out, who was involved, whether they were independent, the methodology and timeline, and the output such as audit reports or compliance plans. Article 26 also allows Commission monitoring actions, including document-retention obligations and independent external experts or auditors.