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 anti-circumvention review is not a generic design sign-off. Article 13 targets practices that avoid gatekeeper designation thresholds or undermine effective compliance with Articles 5, 6, and 7, including through contractual, commercial, technical, behavioral, or interface-design choices. A useful review therefore starts with the designated core platform service, identifies the affected DMA obligation, and asks whether the proposed change preserves the business-user or end-user right in practice.
Run this review before a designated gatekeeper changes a core platform service, 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.
The anti-circumvention 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.
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 anti-circumvention, 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.
Use 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 core platform service, or changed after user feedback.
Article 13 adds an anti-circumvention 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 core platform service 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.
Sorena can help convert this DMA anti-circumvention review into product-change questions, obligation mapping, evidence requests, and compliance-report-ready records.
Ask source-linked questions 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"
"Article 11 DMA - Compliance Report Template Form"
"make the exercise of those rights or choices unduly difficult"