This page helps 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 Article 6(10) gives a access to a defined set of data, not every dataset a gatekeeper holds. On request and free of charge, the gatekeeper must give business users and their authorised third parties effective, high-quality, continuous and real-time access to and use of 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 is covered only when it is directly connected to the end user's use of the relevant business user's product or service and the end user opts in to the sharing by giving consent.
Start with the core platform service listed in the gatekeeper's designation decision. Article 6(10) covers data provided for or generated through that service, or through services provided together with or in support of it, by the and by end users engaging with that business user's products or services.
Do not collapse 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 's request.
Article 6(10) does not create access to unrelated gatekeeper datasets, data generated outside the relevant service context, or every personal-data field the gatekeeper holds. It also does not replace the GDPR or ePrivacy rules: the DMA opt-in condition for personal-data sharing must be handled together with the applicable data-protection and privacy requirements.
A useful intake record should describe the '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. The page helps locate a route; it does not determine whether that route complies with Article 6(10). Test whether the route provides covered data and permits its use with the required effectiveness, quality, continuity, and real-time availability.
Article 6 data rules also restrict gatekeeper use. 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 relevant service context, including data generated or provided by their customers. The paragraph expressly includes aggregated and non-aggregated data that can be inferred from or collected through commercial activity, such as click, search, view, and voice data.
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.
Review 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.
This checklist is Sorena's review aid, not an official Commission form. Its output should be a scoped evidence packet: the applicable Article 6 paragraph, service and data categories, access and use route, personal-data consent treatment, Article 6(2) restriction review, test results, exclusions, and the owner responsible for gaps.
Record the outcome as fulfilled, partially fulfilled with remediation, denied with a stated scope or consent reason, redirected to Article 6(8) or 6(9), or outside Article 6. Reassess when the data schema, consent flow, authorisation model, delivery interface, listed service, business-user product, or gatekeeper use of non-public data changes.
No. Article 6(10) covers access to and use of personal data only where the data is directly connected with the end user's use of the relevant 's product or service through the relevant core platform service, and only when the end user opts in to that sharing by giving 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.
No single request-response period appears in Article 6(10). The binding standard is free, effective, high-quality, continuous and real-time access to and use of the covered data. The gatekeeper should still measure intake and delivery time because delay can make access ineffective, but any internal service level should be identified as an operational control rather than quoted as a DMA deadline.
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 questions tied to cited sources 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"
"aggregated and non-aggregated data"