Check a designated gatekeeper's core platform services against the Digital Markets Act obligations that matter operationally: Articles 5, 6 and 7, Article 11 reporting evidence, Article 13 anti-circumvention, and Article 28 compliance governance.
Keep one row per designated core platform service and obligation so legal, product, engineering, data, developer relations, advertising, and compliance-function owners can prove what changed and where the evidence lives.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this checklist after the Commission has designated an undertaking as a and listed a . Each row turns an applicable Article 5, 6, or 7 paragraph into an owner, control, evidence set, and review trigger for the Article 11 report and non-confidential summary. Keep Article 14 concentration notices and Article 15 audited consumer-profiling descriptions as separate deliverables with their own deadlines and evidence.
Start with the Commission designation decision, not with a product roadmap label. Article 3 requires the designation decision to list the relevant core platform services, and Article 5, Article 6 and Article 7 apply with respect to each listed service.
The Article 3(2) thresholds are a presumption test: at least EUR 7.5 billion in annual Union turnover in each of the last three financial years or at least EUR 75 billion in average market capitalisation or equivalent fair market value in the last financial year; the same in at least three Member States; at least 45 million monthly active Union end users and 10,000 yearly active Union business users in the last financial year; and those user thresholds met in each of the last three financial years. The Commission can also designate below those thresholds after an Article 17 market investigation, and a threshold-meeting undertaking can submit sufficiently substantiated arguments that the Article 3(1) conditions are not met.
A checklist row should be opened only when it names the designated undertaking, the listed , the obligation article and paragraph, the affected business-user or end-user group, and the system or policy owner that can change the service.
Article 5 obligations are directly framed as conduct rules. The checklist should translate each relevant paragraph into an enforceable product, commercial, advertising, payments, account, or complaint-handling control.
Do not close an Article 5 row with a policy statement alone. The row should show the user journey, contract term, system rule, monitoring metric, and exception path that make the obligation effective.
Article 6 contains obligations that often need engineering, data, ranking, default-setting, interoperability, portability, and access-control evidence. Article 7 adds a specific interoperability regime for number-independent interpersonal communications services where that service is listed in the designation decision.
For each technical access obligation, the owner field should name both the policy approver and the system team that can prove the API, interface, data export, ranking change, or default-setting change works in production.
Article 11 requires a detailed and transparent report describing the measures implemented to ensure compliance with Articles 5, 6 and 7, plus a non-confidential summary. The Commission template makes the evidence standard concrete: each obligation and each needs a standalone explanation with supporting data and internal documents.
The evidence pack should be usable by the , management body, external counsel or technical experts, and Commission reviewers without relying on undocumented project history.
A DMA checklist row should not close merely because a control exists. Article 8 requires the to ensure and demonstrate effective compliance, and Article 13 prohibits contractual, commercial, technical, interface-design, or other behaviour that undermines effective compliance.
Use these gates whenever a feature ships, a policy changes, an API is launched or restricted, a business-user complaint identifies friction, or a Commission request or specification process affects the row.
Sorena can help structure DMA gatekeeper questions into obligation rows, owner assignments, source citations, evidence requests, and report-ready summaries for each designated core platform service.
Ask cited questions about DMA gatekeeper obligations, core platform service scope, Article 11 evidence, and interoperability or data-access controls.
Review DMA checklist gaps, owner fields, and report evidence for designated core platform services with Sorena.
"underlying raw data ready to be made available"
"23 core platform services provided by those gatekeepers are currently designated"
"Article 6(7) - Interoperability with OS features"
"shall not engage in any behaviour that undermines effective compliance"