| Scope boundary | Has the Commission designated the undertaking as a gatekeeper, and is the issue tied to a listed core platform service used by EU business users or end users? | Is the activity a digital service covered by the Digital Services Act? Confirm DSA service category and obligations from DSA-specific sources before implementation. | Do not treat a platform as DMA-covered just because it is large or digital. DMA work starts from designation and listed core platform services. |
|---|
| Covered actors | Articles 5, 6, and 7 impose DMA duties on gatekeepers. Examples include limits on data combination without consent, business-user freedom to offer different terms elsewhere, user choice and default changes, third-party app and app-store access, fair ranking, interoperability, portability, business-user data access, and messaging interoperability. | DSA duties should be scoped separately under DSA materials. Do not copy DMA Article 5-7 controls into a DSA checklist without a DSA source. | Map each DMA requirement to the exact listed service and article paragraph before reusing any product, legal, or engineering control for DSA work. |
|---|
| Trigger | DMA Article 6 includes interoperability with operating-system, hardware, and software features in specified contexts; end-user data portability; business-user access to data generated through relevant core platform services; advertiser and publisher measurement access; and search-data access on fair, reasonable, and non-discriminatory terms. | DSA may involve different digital-service governance issues, but those details are outside this DMA-grounded page unless DSA-specific sources are added. | For DMA requests, preserve the request, authorization, technical route, data fields, response, denial rationale, security or privacy justification, and implementation evidence. |
|---|
| Core obligations | Article 11 requires gatekeepers to provide the Commission with a detailed compliance report within six months after designation and to update the report and non-confidential summary at least annually. The Commission template asks for detailed explanations, supporting data, internal documents, technical changes, customer-experience changes, consultations, alternatives, testing, and indicators. | DSA reporting should not be inferred from Article 11 DMA. Keep any DSA transparency or reporting work in a separate source-linked record. | A shared evidence repository can exist, but the Article 11 DMA report needs labels by gatekeeper, core platform service, obligation, measure, evidence type, confidentiality status, and annual update status. |
|---|
| Evidence record | The Commission enforces the DMA against gatekeepers. For DMA non-compliance, Article 30 allows fines not exceeding 10% of total worldwide turnover in the preceding financial year, and up to 20% for the same or similar Article 5, 6, or 7 infringement concerning the same core platform service within the preceding eight years. Separate 1% fines can apply for specified information, notification, access, inspection, compliance-function, and file-access failures. | DSA enforcement and penalty details must be checked in DSA sources. This page does not restate DSA penalty percentages or supervisory allocations from memory. | Escalate DMA risk by article, core platform service, prior non-compliance history, evidence quality, and Commission information requests. Do not quote DMA fine levels as DSA fine levels. |
|---|
| Timing and deadlines | Use DMA when the issue concerns a designated gatekeeper, a listed core platform service, and a DMA obligation, report, interoperability request, data-access right, or Commission enforcement exposure. | Use DSA analysis when the issue concerns obligations under the Digital Services Act. Add DSA-specific sources before stating thresholds, operational duties, deadlines, or penalties. | The safest comparison output is two records: a DMA record grounded in designation, CPS, Article 5-7 duty, Article 11 evidence, and enforcement exposure; and a separate DSA record grounded in DSA materials. |
|---|
| Enforcement | When a DMA issue is already in scope, track which article is implicated, whether the matter is a one-off request or repeat conduct, and whether the evidence package is complete enough for Commission review. | For DSA work, keep the supervisory chain and enforcement record in a separate file so reviewers do not assume DMA enforcement mechanics apply unchanged. | Use enforcement rows to document who can ask for what, which evidence must be kept ready, and when escalation is needed. Do not reuse this row as a scope test. |
|---|
| Overlap and reuse | A service can need both a DMA and a DSA review, but the analysis should be split into separate records so the evidence, owner, and decision path are clear. | If the same product also falls under the Digital Services Act, document that in a separate DSA workstream instead of folding it into the DMA checklist. | Reuse common facts, but not the legal test. The DMA test stays centered on designation, core platform service scope, and the Article 5-7 duty at issue. |
|---|
| Practical decision rule | Start with the DMA question: is there a designated gatekeeper, a listed core platform service, and a specific Article 5, 6, or 7 issue that needs evidence or remediation? | Then ask whether the same service also needs a DSA review, and route that work to DSA-specific sources rather than borrowing DMA thresholds or penalties. | If the answer is unclear, split the workstream. A clean split prevents mixed obligations, mixed evidence, and mixed ownership. |
|---|