User choice and steering
Document the user journey, default state, prompts, fees, links, and restrictions that affect a user's or business user's ability to choose alternatives. Test both intended and edge-case paths.
Policy guide
Run digital-markets compliance as a designation-and-obligation system.
Digital-platform rules are not one global checklist. Start with the exact service, jurisdiction, designation, legal instrument, and regulator action that applies; then connect those obligations to product decisions, engineering evidence, commercial terms, and accountable owners.
Substantively reviewed . This revision corrects the UK statutory citation, removes outdated designation assumptions, corrects the scope of DMA Article 7, and replaces January 2025 status statements with current Commission and CMA records.
Applicability first
Do not treat the DMA, DSA, UK regime, and U.S. antitrust law as interchangeable.
The European Union's Digital Markets Act (DMA) applies specific obligations to designated gatekeepers and their designated core platform services. The Digital Services Act (DSA) regulates intermediary services more broadly and adds enhanced obligations for designated very large online platforms and very large online search engines. The United Kingdom's Digital Markets, Competition and Consumers Act 2024 creates a separate Strategic Market Status (SMS) regime in which the Competition and Markets Authority can designate firms for particular digital activities and impose targeted conduct requirements or other interventions. U.S. antitrust law is different again: the Sherman and Clayton Acts remain competition statutes rather than a copy of the EU or UK designation model.
That distinction should shape the compliance architecture. A product team should not receive a generic instruction such as “comply with digital markets law.” It should receive a traceable requirement tied to the affected service, legal basis, designation or enforcement action, effective status, responsible owner, technical behavior, evidence, and review trigger.
This guide is operational implementation guidance, not legal advice. Legal and regulatory teams should determine applicability and interpret binding obligations for the organization.
Status snapshot
Use live regulator records because the designation state changes.
European Union
The Commission's Gatekeepers Portal is the operational starting point for DMA designation status. As of this review, it records seven gatekeepers—Alphabet, Amazon, Apple, Booking, ByteDance, Meta, and Microsoft—and 23 designated core platform services. It also records changes such as the April 2025 removal of Facebook Marketplace from Meta's designation. Do not hard-code an old gatekeeper list into policy or product documentation.
Enforcement is active rather than hypothetical. On July 23, 2026, the Commission announced two DMA non-compliance decisions against Google concerning self-preferencing in Search and steering restrictions in Google Play, with combined fines of €890 million. The practical lesson is that compliance teams need evidence of real product behavior, not only policy statements.
The DSA has its own designation and supervision record for VLOPs and VLOSEs. The Commission maintains a live list with enforcement activity for each designated service. Keep that record separate from DMA designation because the legal duties and service scopes differ.
United Kingdom
The UK digital markets competition regime took effect on January 1, 2025. The CMA subsequently designated Google with SMS for general search and search advertising and designated Apple and Google with SMS for their mobile platforms in October 2025.
By 2026 the regime had moved beyond designation. The CMA imposed search-related conduct requirements on Google, including publisher, fair-ranking, and data-portability requirements, while continuing work across the Apple and Google mobile ecosystems. The CMA also opened an SMS investigation into Microsoft's business software ecosystem in May 2026.
That sequence matters operationally: SMS designation does not itself mean every possible conduct requirement applies. Track each imposed requirement, commitment, investigation, consultation, and effective date against the exact digital activity.
Current-state sources: EU DMA Gatekeepers Portal, DMA latest news, DSA VLOP/VLOSE supervision list, and current CMA digital-markets case records.
Legal baseline
Keep the durable statutory structure separate from the changing case state.
EU DMA
The DMA establishes the gatekeeper designation process and obligations for designated core platform services. Articles 5 and 6 contain obligations and prohibitions concerning areas such as data use, steering, access, defaults, ranking, interoperability with operating-system features, and data portability or access, depending on the service and provision.
Article 7 is narrower than the previous version of this guide stated. It concerns interoperability for number-independent interpersonal communications services. It is not a general FRAND rule for app stores, search engines, and social networks.
Use the Commission's live case materials and specification proceedings to understand how individual provisions are being applied. For example, in July 2026 the Commission adopted specification measures concerning AI interoperability on Android and sharing of Google Search data under Article 6(11).
EU DSA
The DSA applies a layered framework to intermediary services, with additional obligations for VLOPs and VLOSEs. Depending on service type and designation, obligations can involve notice-and-action processes, transparency, recommender-system disclosures, advertising transparency, risk assessment, mitigation, independent audits, researcher or regulator data access, and other duties.
Do not infer DSA status from DMA status. A service can be relevant to one regime, both, or neither, and the designated entity or service boundary can differ.
UK DMCC Act 2024
The Digital Markets, Competition and Consumers Act 2024 is 2024 c.13. Part 1 creates the digital markets competition regime. The CMA can investigate and designate firms with SMS in relation to a digital activity, impose conduct requirements, pursue pro-competition interventions, and use enforcement powers provided by the Act.
Use the CMA's case pages and published measures as the current record of what has actually been imposed. The regime is intentionally targeted, so product requirements should not be copied from one SMS firm's measure to another without a legal basis.
United States
The Sherman Act and Clayton Act remain central federal antitrust statutes. Product, commercial, distribution, exclusivity, tying, acquisition, access, and interoperability decisions can create competition-law risk, but U.S. obligations should not be represented as if they were DMA-style gatekeeper duties.
For consequential product or transaction decisions, legal teams should evaluate the current case law, agency posture, market definition, competitive effects, and the facts of the conduct rather than treating this guide as a statutory checklist.
Control foundation
Maintain an obligation register that starts with the service, not the statute name.
A useful register lets engineering and product teams answer one question quickly: what behavior must this service demonstrate, and why?
| Field | Record | Purpose |
|---|---|---|
| Entity and service | Legal entity, product/service, geography, designated activity or core platform service | Prevents obligations from leaking to the wrong product |
| Authority | Statute, article/section, designation decision, conduct requirement, commitment, order, or case | Creates traceability |
| Status | Proposed, consulted, imposed, effective, stayed, appealed, superseded, closed | Separates future risk from current duty |
| Behavior | What the product, commercial process, ranking, data flow, interface, or user choice must do | Makes the requirement testable |
| Owner | Legal owner, product owner, engineering owner, evidence owner | Prevents orphaned requirements |
| Evidence | Configuration, test, UI capture, API result, log, report, policy, data-flow record, approval | Shows the behavior exists in production |
| Review trigger | Release, regulator action, designation change, consultation outcome, enforcement decision | Keeps the register current |
Product operations
Turn legal requirements into bounded product controls.
Most implementation failures happen between legal interpretation and shipped behavior. Use a control contract for every material obligation: what state is required, where it is implemented, how it is tested, what data proves it, and who can approve an exception.
Ranking and self-preferencing
Version ranking policies, product placements, eligibility logic, exceptions, and experiments. Preserve evidence that can reconstruct how first-party and third-party services are treated.
Interoperability
Treat interoperability as an API and governance lifecycle: eligibility, authentication, documented capabilities, security controls, versioning, performance, change notice, abuse handling, and evidence of equivalent access where required.
Data access and portability
Define the eligible data, beneficiary, purpose, latency, format, authentication, privacy controls, retention, revocation, and test evidence. Do not use a generic export feature as proof of every legal data-access duty.
Data combination and consent
Map each data source, purpose, lawful choice or consent mechanism, equivalent alternative where required, downstream use, and withdrawal path. Verify the actual data pipeline, not only the user-facing text.
Commercial terms
Version fees, commissions, access terms, eligibility rules, partner agreements, and enforcement logic. Legal review should be tied to product and contract changes rather than annual policy review alone.
Evidence
Prove the production behavior, not just the governance process.
- Link every obligation to a release artifact. Identify the feature flag, configuration, API version, user-interface flow, ranking policy, commercial term, or data pipeline that implements it.
- Test both positive and negative paths. Prove the required access or choice works and that prohibited restrictions do not reappear under common edge cases.
- Preserve change history. Store approvals, test evidence, design decisions, regulator correspondence, and the state actually deployed at each material release.
- Separate legal conclusions from technical facts. Engineering evidence should show behavior; legal records should explain why that behavior is sufficient or required.
- Monitor drift. A compliant design can become non-compliant after an experiment, fee change, default change, ranking update, acquisition, data-source integration, or partner-policy revision.
Change management
Give high-change legal content a short review cycle.
Digital-markets compliance is unusually sensitive to designation decisions, specification proceedings, conduct requirements, commitments, market investigations, appeals, and enforcement decisions. A static annual legal review is not enough for teams shipping affected services.
- Review regulator case pages monthly for services already designated or under active investigation.
- Trigger immediate review when the Commission or CMA publishes a designation, non-compliance decision, conduct requirement, specification measure, commitment, consultation outcome, or material case update.
- Require legal review in the product lifecycle for ranking, defaults, app-store rules, interoperability, data access, advertising, consent, bundling, fees, exclusivity, acquisitions, and major partner-policy changes when they intersect an applicable regime.
- Keep historical snapshots so the organization can show what requirement and product state existed at the time a decision was made.
Practical start
A 30-day digital-markets compliance reset.
- Days 1–5: enumerate services and designations. Build the entity/service/jurisdiction inventory and link each item to the current regulator record.
- Days 6–10: build the obligation register. Capture the exact applicable article, order, conduct requirement, commitment, or case status and assign legal and product owners.
- Days 11–15: map product behavior. Identify the code, configuration, UI, API, data flow, ranking system, or commercial term implementing each material obligation.
- Days 16–20: test evidence. Run representative user, business-user, developer, and partner journeys. Capture results and exceptions.
- Days 21–25: inspect change triggers. Review release processes, experiments, fee changes, default changes, data integrations, and partner-policy updates for gaps in legal review.
- Days 26–30: publish the risk backlog. Separate confirmed current obligations, pending regulatory changes, unresolved legal questions, and product-control defects. Give each a named owner and next decision date.
Primary sources
Current authorities used for this review.
- Regulation (EU) 2022/1925 — Digital Markets Act.
- European Commission — DMA Gatekeepers Portal.
- European Commission — latest DMA actions.
- Regulation (EU) 2022/2065 — Digital Services Act.
- European Commission — supervision of designated VLOPs and VLOSEs.
- Digital Markets, Competition and Consumers Act 2024, c.13.
- CMA — Digital markets competition regime guidance.
- CMA — Google's general search and search advertising services.
- CMA — Google's mobile platform.
- CMA — Microsoft's business software ecosystem SMS investigation.
- 15 U.S.C. Chapter 1 — Sherman Act provisions.
- 15 U.S.C. §18 — Clayton Act Section 7.
Review note: regulator designation and enforcement status can change faster than the durable operating practices in this guide. Zeph Tech revalidates current-law pages on a shorter review cycle and may withhold them from primary discovery when current-state confidence is insufficient.
Related operating guides
Put this guide to work
Turn Digital Markets Compliance Guide into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.