A focused review format for product, interface, commercial, contractual, and technical changes that could undermine a gatekeeper's DMA obligations.
Use it to map a change to Articles 5, 6, and 7, test whether rights or choices become harder to exercise, and preserve evidence suitable for Article 11 compliance reporting.
Structured answer sets in this page tree.
Cited legal and guidance references.
DMA Article 13 prohibits service fragmentation used to avoid Article 3 thresholds and conduct that undermines effective compliance with Articles 5, 6, and 7, including contractual, commercial, technical, behavioural, and interface-design choices. Start with the listed and exact underlying obligation. The review should end with a recorded pass, conditional pass with required changes, or block decision, plus the evidence and monitoring trigger. Security, integrity, or privacy restrictions are available only where the mapped obligation permits them and their stated conditions are met.
Run this review before a designated gatekeeper changes a , adjacent support service, user interface, API, ranking system, consent flow, access condition, fee model, business-user term, interoperability process, data-access process, or enforcement workflow that implements or touches a DMA Article 5, 6, or 7 obligation.
The review should also cover changes that split a service, recategorize usage, move functionality between services, add friction to an alternative channel, or change how users exercise a DMA right. Article 13 expressly covers segmentation or fragmentation used to circumvent designation thresholds and behavior that undermines effective compliance.
Keep the pre-designation threshold branch separate from the gatekeeper-compliance branch. Article 13(1) addresses an undertaking providing core platform services that fragments them to avoid thresholds. Article 13(3) to (8) addresses a gatekeeper's full and effective compliance with Articles 5, 6, and 7.
The question depends on the underlying obligation. A payment-flow change should be tested against the Article 5 and Article 6 rights it affects; an API or operating-system change should be tested against the relevant interoperability or access obligation; a consent or choice-screen change should be tested against whether the user's choice remains neutral and practicable.
Do not approve a change only because the formal obligation text is still mentioned in policy. The review has to test whether the implemented product path remains effective for the business user, end user, advertiser, publisher, developer, or third-party provider that the obligation is meant to protect.
A design review should have stop conditions, not just comments. If a change affects a DMA right, the approver should be able to point to a test result, user journey, or technical record showing that the right remains usable and that any security, integrity, or privacy restriction is justified and proportionate.
Article 13 makes interface structure, design, function, and manner of operation relevant. That means dark-pattern testing, neutral presentation checks, friction analysis, and degradation checks belong in the product release control. A security, integrity, or privacy concern is not a free-standing Article 13 exception; the underlying obligation must permit the measure, and the gatekeeper must satisfy that obligation's necessity, proportionality, and justification conditions.
The evidence pack should let a reviewer reconstruct how the change affected a specific DMA obligation. Article 11 reporting expects detailed and transparent descriptions of compliance measures, and the Commission template asks for product scope, geographic scope, technical changes, customer-experience changes, consultations, alternatives, testing, indicators, and monitoring tools.
For , keep both approval evidence and rejected alternatives. The rejected-alternatives record is important where a gatekeeper chooses a more restrictive access path, warning, choice architecture, fee rule, or technical limitation.
Run this checklist at the release gate for DMA-relevant product and policy changes. The goal is to show that the change preserves effective compliance, not merely that the team considered DMA in general terms.
The checklist should be attached to the product-change record and reused when the same feature is localized, extended to another , or changed after user feedback.
Article 13 adds an test. A gatekeeper should check whether a design, interface, contractual term, commercial condition, technical measure, behavioral technique, or service split undermines effective compliance with Articles 5, 6, or 7, even if the formal product policy still refers to the DMA obligation.
The strongest evidence ties the change to a specific and DMA obligation, then shows the before-and-after user journey, technical implementation, access conditions, testing or indicators, complaints or feedback, rejected alternatives, and any security, integrity, or privacy justification.
The DMA allows certain strictly necessary and proportionate security, integrity, or privacy measures in specific obligations, but the gatekeeper should document the reason, the affected right, the alternatives considered, and why the chosen measure does not make the right unduly difficult to exercise.
No. Article 13(1) applies to an undertaking providing core platform services and prevents it from splitting or fragmenting services to circumvent the Article 3(2) thresholds. Article 13(3) to (8) governs a designated gatekeeper's full and effective compliance with Articles 5, 6, and 7.
Sorena can help convert this DMA anti-circumvention review into product-change questions, obligation mapping, evidence requests, and compliance-report-ready records.
Ask questions tied to cited sources about Article 13, gatekeeper obligations, design changes, and evidence records using the cited DMA sources.
Review a DMA-relevant product change, map it to Articles 5, 6, or 7, and identify the evidence needed before release.
"internal systems and tools used to monitor"
"Core platform services"
"designation of gatekeepers and the implementation of the obligations"
"make the exercise of those rights or choices unduly difficult"