Artifact GuideEU

EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams

A practical playbook for building DMA compliance into product and engineering decisions.

Optimised for teams shipping within the 6-month post-designation deadline and documenting evidence for Article 11.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 21, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 21, 2026

Updated Feb 23, 2026

Overview

DMA compliance becomes real in product decisions: ranking changes, default settings, app distribution flows, consent prompts, and APIs. This playbook focuses on what product and engineering teams should do (and avoid) when building DMA changes per core platform service (CPS).

Section 1

Do: treat DMA as product requirements per CPS

DMA obligations attach to each core platform service (CPS) listed in the designation decision. That means compliance must be implemented and tested per CPS surface, not just declared in policy.

Use a CPS-by-CPS requirements doc that maps Articles 5-7 obligations to features, owners, and acceptance criteria.

Create an obligation-to-feature map per CPS and track it in your product backlog.
Define measurable acceptance criteria (e.g., default change succeeds, uninstall path works, portability export completes, request SLAs met).
Add a DMA review gate to launches that affect ranking, discovery, distribution, identity, payments, consent, and cross-service data flows.

Section 2

Don't: bury preferential treatment in ranking, indexing, or experiments

DMA Article 6(5) prohibits self-preferencing in ranking and requires transparent, fair, non-discriminatory conditions.

Self-preferencing often hides in "harmless" experiments and hand-tuned boosts. If you cannot explain ranking changes, you cannot defend them.

Avoid hard-coded boosts/whitelists for first-party content, services, or products.
Avoid asymmetric eligibility rules (faster indexing, looser quality thresholds) for first-party offerings.
Do build ranking governance: feature/parameter registry, experiment approvals, parity tests, and monitoring.

Section 3

Do: build real choice (defaults, uninstall, and distribution)

DMA Article 6 includes obligations that drive UX and OS/app-store changes: uninstallability, default settings and choice prompts, and enabling third-party apps/app stores.

These obligations are best implemented with testable flows and clear logging so you can prove effectiveness.

Implement easy uninstall of apps (except those essential to OS/device functioning).
Enable easy default changes; prompt end users at first use to choose among main providers for search engine, virtual assistant, and browser where applicable.
Enable installation and effective use of third-party apps and app stores using/interoperating with the OS, including access by means other than the gatekeeper CPS, subject to strictly necessary and proportionate integrity/security measures.

Section 4

Don't: treat consent/data combination as a UI problem only

DMA Article 5(2) restricts combining/cross-using personal data across services without specific choice and consent; it also limits repeated requests if consent is refused or withdrawn.

This is a systems problem: data pipelines, identity graphs, consent state storage, and enforcement in downstream processing.

Avoid "binary choice" designs that effectively force consent to combine data as a condition to use the service's core value.
Do implement consent enforcement in data systems (not just in UI): gating, audit logs, and testing of downstream usage.
Do design "less personalised but equivalent" experiences where relevant and measurable.

Section 5

Do: treat portability and access as APIs with SLAs

Article 6 requires effective data portability for end users and continuous/real-time access to data, plus data access for business users (with consent constraints for personal data).

Build this like a platform capability: APIs, documentation, rate limits, monitoring, and support processes.

Portability tooling: continuous and real-time access, export formats, and clear documentation.
Business-user data access: high-quality, continuous, real-time access to aggregated and non-aggregated data generated in CPS use; personal data sharing only with end-user opt-in consent.
Operational readiness: observability, error budgets, and an escalation path when portability/access fails.

Section 6

Do: capture evidence as you ship (Article 11 compliance report ready)

The Commission's Article 11 compliance report template expects detailed explanations of measures per CPS and per obligation, supported by data, internal docs, and often recorded demos.

If evidence capture is an afterthought, compliance becomes a documentation scramble.

Record prior state vs new state: screenshots, flows, API docs, and change logs.
Capture implementation metadata: implementation date, scope (products/devices), geographic scope, and engineering details (APIs, ranking parameters, security measures).
Keep underlying raw data ready and store evidence in machine-readable formats where possible.

Recommended next step

Use EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams as a cited research workflow

Research Copilot can take EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Research workflow

Open Research Copilot for EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams

Start from EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams and answer scope, timing, and interpretation questions with cited outputs.

Explore next step

Talk to Sorena

Talk through EU Digital Markets Act (DMA)

Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams.

Explore next step

Primary sources