Use this page to scope Article 6 data-access work for a designated gatekeeper core platform service without turning it into a generic privacy, API, or reporting checklist.
It separates business-user access under Article 6(10), end-user portability under Article 6(9), non-public business-user data restrictions under Article 6(2), and the evidence expected in DMA compliance reporting.
Structured answer sets in this page tree.
Cited legal and guidance references.
DMA business-user data access is not a broad entitlement to every dataset a gatekeeper holds. Article 6(10) requires a gatekeeper, on request and free of charge, to give business users and their authorised third parties effective, high-quality, continuous and real-time access to aggregated and non-aggregated data provided for or generated through the relevant core platform service by those business users and by end users engaging with their products or services. Personal data access is narrower: the data must be directly connected to the end user's use of the relevant business user's product or service, and the end user must opt in by consent.
Start with the designated core platform service. The Article 6(10) access duty attaches to the relevant core platform service, and to services provided together with or in support of it, when the data was provided for or generated in that context by the business user and by end users engaging with that business user's offer.
Do not collapse Article 6(10) into Article 6(9). Article 6(9) is end-user portability for data provided by the end user or generated through the end user's activity, including continuous and real-time access. Article 6(10) is the business-user data-access obligation, including authorised third-party access on the business user's request.
A useful intake record should describe the business user's product or service, the relevant gatekeeper interface, the requested data categories, whether the data is aggregated or non-aggregated, and whether personal data is included. It should also state whether the requester is the business user or an authorised third party.
The Commission's business-resource page lists gatekeeper access routes such as data-access documentation, dashboards, portals, APIs, and request forms. That list supports the handoff pattern, but it does not prove that any one technical route is sufficient for Article 6(10). Product teams should therefore review whether the available route actually delivers the scope, quality, continuity, and timeliness the obligation requires.
Article 6 data access has a defensive side as well as an access side. Article 6(2) prohibits a gatekeeper from using, in competition with business users, non-public data generated or provided by those business users in the context of their use of the relevant core platform service, including data generated or provided by their customers.
Product review should therefore test both directions: whether business users can obtain the data Article 6(10) covers, and whether internal gatekeeper uses of non-public business-user data are blocked where Article 6(2) applies. A launch that expands ranking, ads, analytics, marketplace insights, AI training inputs, recommendation features, or internal competitive benchmarking can reopen both questions.
Evidence should prove the substance of access, not just the existence of a policy. Keep the business-user request, authorisation documents for third parties, data-category mapping, consent handling for personal data, delivery method, error logs, denials, partial responses, and follow-up communications.
The DMA compliance-report template points to a broader evidence package: measures implemented, changes to business-user terms, consultations, actions to inform business users, security or privacy measures, testing, indicators, underlying data, and monitoring systems. For Article 6(10), those records should connect the legal scope to the actual access mechanism and to measurable outcomes such as request counts, fulfilled requests, rejected requests, latency, completeness, and data-quality issues.
Use this checklist before approving a DMA data-access mechanism, a business-user dashboard, a data export, a third-party authorisation flow, or a product change that touches business-user generated data.
The expected output is a scoped evidence packet: the Article 6 paragraph, the service and data categories, the access route, the personal-data consent treatment, the restriction review, test results, and the owner who can fix gaps.
No. Article 6(10) covers personal data only where it is directly connected with the end user's use of the relevant business user's product or service through the relevant core platform service, and only when the end user opts in by consent.
Not by itself. The DMA requires effective, high-quality, continuous and real-time access where Article 6(10) applies. An API, export, dashboard, or request form is evidence only if it delivers the covered data with the required scope and quality.
Keep the request, authorisation, data-category map, consent treatment, access route, fulfilled and rejected responses, quality and latency tests, security or privacy limits, and the indicators used to show effective compliance.
Sorena can help compare a business-user request, data categories, consent handling, access route, and product-change evidence against the DMA sources cited on this page.
Ask source-linked questions about Article 6 data access, end-user portability, gatekeeper scope, and compliance-report evidence.
Review your business-user access route, consent boundaries, product-change checks, and compliance evidence with Sorena.
"demonstrate effective compliance"
"designated gatekeepers"
"Article 6(9) - End user data portability"
"aggregated and non-aggregated data"