Use this release-control record before a change ships on a . Name the affected service, map the changed facts to Articles 5, 6, and 7 and the Article 13 rule, collect evidence that can support the next Article 11 report, and record product and legal approval. This is an internal control, not a Commission-prescribed approval form.
1
Section 1
When to open a DMA release review
Open this workflow when a release changes how a handles data, ranking, access terms, interoperability, user choice, ads measurement, app-store behavior, defaults, portability, business-user data, or complaint channels.
Check scope first. Article 5, Article 6 and Article 7 obligations apply by reference to each core platform service listed in the gatekeeper designation decision, so the review record should name the designated service, the user groups affected, and the exact release artifact being approved.
End the intake step with one recorded branch: outside scope because no listed service or applicable obligation is affected; in scope with no control change; in scope and approved with complete evidence; conditionally approved with a named pre-release action; or blocked and escalated. A legal interpretation, security concern, or Commission specification issue that could change the result remains open until the responsible owner resolves it.
Record the , product area, release version, rollout geography, affected end users and affected business users.
State whether the release changes a user journey, API, data flow, ranking parameter, access condition, fee, contract term, consent flow, warning message, default setting or interoperability request process.
Do not approve the release while an affected obligation remains unmapped or a material legal interpretation remains unresolved. The DMA itself does not prescribe this internal approval gate.
Attach product-owner and legal-owner names to the review before engineering approval is treated as complete.
Commission page identifying currently designated gatekeepers and core platform services for scope checks.
23 core platform services provided by those gatekeepers
2
Section 2
Article 5 release checks
Article 5 checks should run before any launch that changes consent, cross-service data use, business-user communications, off-platform offers, payment or identity requirements, tying of core platform services, or advertising transparency outputs.
Treat an Article 5 issue as a release blocker unless legal approves the interpretation and product confirms the user journey, business-user journey, and evidence record.
Data and consent: confirm the release does not newly combine, cross-use, or sign users into services for personal-data combination without the required specific choice and consent.
Business-user freedom: confirm the release does not prevent different prices or conditions through third-party channels or direct sales channels.
Communication and access: confirm business users can promote offers and conclude contracts with acquired end users, and that end users can access purchased content, subscriptions, features or items through the business user's application.
No forced services: check Article 5(7) by actor and condition. A gatekeeper must not require end users to use, or business users to use, offer, or interoperate with, its identification service, web browser engine, payment service, or technical service supporting payment services in the context of services provided by business users through its listed core platform services. Separately, Article 5(8) restricts requiring subscription to or registration with another listed core platform service, or one that meets the Article 3(2)(b) thresholds, as a condition of using the listed service.
Ads transparency: if online advertising is affected, confirm the release preserves daily, free-of-charge advertiser and publisher information flows required by Article 5.
Article 5 sets obligations covering consent-based data processing, anti-steering restrictions, access to purchased content, tying limits, complaint rights, and advertising transparency.
The gatekeeper shall not do any of the following
3
Section 3
Article 6 release checks: data access, self-preferencing and access terms
Article 6 checks are needed when a release changes ranking, search, app-store access, operating-system defaults, app installation paths, ad measurement tools, business-user data access, end-user portability, search data access, or termination conditions.
The review should compare the pre-release and post-release state. For DMA evidence, a bare control description is not enough; the team should show what changed in data flows, ranking logic, APIs, OS features, user screens, terms, fees, and operational queues.
Business-user data: confirm the gatekeeper is not using non-public data generated or provided by business users, or their customers, to compete with those business users.
Self-preferencing: confirm ranking, indexing and crawling do not treat the gatekeeper's own services or products more favourably than similar third-party services or products, and document ranking-condition changes.
Interoperability and access: confirm providers of services and hardware receive free, effective interoperability with relevant hardware and software features where Article 6(7) applies.
Measurement and ads data: confirm advertisers, publishers and authorised third parties retain free access to performance measuring tools and data needed for independent verification.
Portability and business-user data access: confirm end-user portability tools and business-user access to aggregated and non-aggregated data remain effective, high-quality, continuous and real-time where required.
and termination: confirm app-store, search-engine and social-network access conditions remain fair, reasonable and non-discriminatory, and that core platform service termination conditions are not disproportionate.
Commission business resources page for practical DMA access, portability and interoperability materials.
Resources for businesses
4
Section 4
Article 7 and interoperability request checks
For number-independent interpersonal communications services, Article 7 requires a separate interoperability review. The release record should state whether the change affects technical interfaces, reference offers, security, end-to-end encryption, request intake, or the data exchanged for interoperability.
For operating-system and device interoperability under Article 6(7), use the same release gate for technical documentation, request queues, developer communications, access to features, integrity justifications, and predictable handling of requests.
Article 7 service fit: identify whether the designated service is a number-independent interpersonal communications service and whether the change affects a listed basic functionality. Track the staged Article 7(2) deadlines: individual text messaging and attached files within the Article 3(10) period, group messaging within two years after designation, and individual or group voice and video calls within four years after designation.
Reference offer: confirm the published interoperability terms and technical details remain accurate after the release.
Reasonable requests: record the receipt date, requested functionality, decision, technical work, and operational date. Article 7(5) requires a reasonable request to be made operational within three months after receipt unless the Commission grants an exceptional extension under Article 7(6).
Security and privacy: document any integrity, security or privacy measure as strictly necessary, proportionate and justified, rather than as a general refusal reason.
Personal data minimisation: confirm the release exchanges only personal data strictly necessary to provide effective interoperability.
Commission example of specification decisions requiring clearer technical documentation, timely communication and predictable review of interoperability requests.
transparency and effectiveness of the process
5
Section 5
Article 13 anti-circumvention review
Check Article 13 after mapping Articles 5, 6, and 7. The review asks whether the complete design, commercial terms, or technical implementation undermines those obligations through fragmentation, degraded quality or conditions, non-neutral choices, or undue difficulty.
The review should be conducted from the perspective of affected business users and end users, not only from the perspective of the internal product design.
Service segmentation: confirm the release does not segment, divide, subdivide, fragment or split core platform services to avoid DMA thresholds or scope.
Effective compliance: confirm contractual, commercial, technical and interface-design changes do not undermine obligations under Articles 5, 6 or 7.
No degradation: confirm users who exercise DMA rights do not receive worse conditions or lower service quality because they used those rights.
No undue difficulty: confirm the release does not make rights or choices harder to exercise through extra steps, confusing screens, degraded defaults or behavioural nudges.
Neutral choices: test choice screens, consent flows, warnings and developer-request flows for non-neutral presentation.
Article 13 prohibits circumvention through technical, contractual, commercial, behavioural or interface-design means and prohibits degrading conditions for users exercising DMA rights.
shall not engage in any behaviour
6
Section 6
Article 11 evidence pack and signoff
Close the workflow with an Article 11-ready evidence pack. The Commission template expects standalone information for each core platform service and applicable Articles 5 to 7 obligation, with a compliance statement, detailed explanation, supporting data and internal documents.
The product owner should sign for the release facts and operational implementation. Legal should sign for the obligation mapping, interpretation, assessment, and whether the release needs to be reflected in the next compliance report or non-confidential summary.
Compliance statement: identify the Article and paragraph reviewed, the core platform service, the launch date or planned launch date, and whether the release maintains or changes compliance measures.
Before-and-after evidence: capture the prior situation, new measure, implementation date, product/service/device scope, geographic scope and affected user journeys.
Technical evidence: attach data-flow diagrams, API or OS-functionality changes, ranking parameters, auction or measurement changes, security justifications, logs, test results, screenshots, demos or recorded walkthroughs where relevant.
Commercial and terms evidence: attach fee changes, access terms, privacy notices, contract clauses, dispute mechanisms, developer documentation and customer communications affected by the release.
Consultation and request evidence: record business-user, end-user, developer or interested-party input where used, plus request tickets and response records for access, data, portability or interoperability flows.
Approval gate: require named product-owner, engineering-owner, data-governance-owner and legal-owner approval before release, and store the final decision with the source citations used for the review.
Post-release gate: name the production verification date, monitoring indicator, complaint or request queue, evidence owner, Article 11 annex or public-summary section to update, and reopening triggers. Reopen the review if rollout facts differ from the approved design, monitoring shows the measure is ineffective, a user journey degrades, a new Commission decision or request changes the analysis, or the designated-service boundary changes.
Article 11 requires gatekeepers to report measures implemented to ensure compliance with Articles 5, 6 and 7 and to update the report and non-confidential summary at least annually.
Commission template specifying minimum Article 11 report information, including compliance statements, supporting data, internal documents, technical changes, user journeys, terms and consultation records.
Recommended next step
This DMA workflow is a release gate
Sorena can help convert product changes into cited DMA review records with obligation mapping, Article 11 evidence fields, anti-circumvention checks and signoff routing.
Primary legal text for Articles 5, 6, 7, 8, 11 and 13 product-release checks.
Article 5, Article 6 and Article 7 obligations are tied to designated gatekeepers and their listed core platform services.
Article 5 sets obligations covering consent-based data processing, anti-steering restrictions, access to purchased content, tying limits, complaint rights, and advertising transparency.
Show 4 more
Article 6 covers non-public business-user data use, self-preferencing, interoperability, ad-measurement access, portability, business-user data access, search data access, FRAND access conditions, and termination conditions.
Article 7 sets interoperability duties for number-independent interpersonal communications services, including reference offers, reasonable requests, security and data-minimisation conditions.
Article 13 prohibits circumvention through technical, contractual, commercial, behavioural or interface-design means and prohibits degrading conditions for users exercising DMA rights.
Article 11 requires gatekeepers to report measures implemented to ensure compliance with Articles 5, 6 and 7 and to update the report and non-confidential summary at least annually.
"ensure and demonstrate compliance"
More quoted passages
"with respect to each of its core platform services"
"The gatekeeper shall not do any of the following"
"transparent, fair and non-discriminatory conditions"
Commission example of DMA specification measures for interoperability request processes, documentation, communications and timing.
Commission example of specification decisions requiring clearer technical documentation, timely communication and predictable review of interoperability requests.
Commission template for evidence expected in Article 11 compliance reporting, including supporting data, internal documents, technical changes, user journeys, terms and consultation records.
Commission template specifying minimum Article 11 report information, including compliance statements, supporting data, internal documents, technical changes, user journeys, terms and consultation records.