DMA product change release review workflow

Open this workflow when a release changes how a designated core platform service handles data, ranking, access terms, interoperability, user choice, ads measurement, app-store behavior, defaults, portability, business-user data, or complaint channels.

The first checkpoint is scope. 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.

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.

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.

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, security justifications, and predictable handling of requests.

Article 13 should be checked after the Article 5, 6 and 7 mapping. A release may look compliant at the obligation level but still undermine the effective exercise of DMA rights through design, commercial terms, technical fragmentation, degraded quality, non-neutral choices or unnecessary friction.

The anti-circumvention review should be conducted from the perspective of affected business users and end users, not only from the perspective of the internal product design.

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, anti-circumvention assessment, and whether the release needs to be reflected in the next compliance report or non-confidential summary.