EU Market Surveillance Regulation (MSR) vs Digital Services Act (DSA) marketplace boundary

Is a covered product being made available, placed on the market, put into service, imported, offered online, or otherwise handled by an economic operator under Union harmonisation law?

Is the unresolved question about the online service or intermediary workflow rather than the product's conformity, EU economic operator, customs status, or corrective action?

Start with the product facts. If a product role exists, run the MSR analysis even if a platform or DSA workstream also exists.

Name the manufacturer, authorised representative, importer, distributor, fulfilment service provider, or other economic operator that owns the MSR product duty.

Name a separate DSA owner only after a DSA-source review confirms the online-service role and duty; do not infer it from the MSR economic-operator label.

A marketplace may need two owners: one for product compliance and one for online-service governance. Do not let either label erase the other.

For listed product legislation, confirm the EU-established economic operator responsible for Article 4 tasks before the product is placed on the EU market.

A DSA analysis does not supersede the Article 4 check; if no DSA grounding is available, leave DSA status open rather than using it as an Article 4 shortcut.

Keep a product-level Article 4 record even when the sales journey starts through an online marketplace.

MSR treats products offered online or through other distance-sales means as made available on the market when the offer is targeted at end users in the Union.

A separate DSA review may still be needed for the online-service workflow, but it should not decide whether the product offer is targeted at EU end users for MSR purposes.

Marketplace intake should ask both questions: product offer targeted to the EU for MSR, and online-service obligations for DSA if separately sourced.

MSR covers controls on products entering the Union market, including risk-based checks, suspension of release for free circulation, authority decisions, and follow-up on non-compliant or serious-risk products.

Do not route customs holds, release decisions, or product non-compliance findings to a DSA-only workflow; those are MSR and customs-control records first.

Keep customs documents, authority notices, release or refusal decisions, and corrective-action evidence in the MSR file even if marketplace teams also support customer messaging.

MSR records may include market-surveillance authority requests, online-interface removal or warning measures, ICSMS entries, Safety Gate alerts, EUPCN coordination context, and corrective-action evidence.

Keep DSA records separate unless a DSA-source review confirms the same artifact has a DSA purpose; shared screenshots or logs should be tagged by law and claim.

A shared evidence index is useful, but every artifact needs a tag showing whether it supports MSR, DSA, or only a factual marketplace record.

Use MSR as the active workstream when the blocker is product conformity, Article 4, EU contact details, online product offer, fulfilment, customs release, authority request, corrective action, ICSMS, or Safety Gate.

Use a separate DSA workstream when the blocker is an online-service or intermediary-governance question and the DSA source review has been completed.

The practical answer can be MSR only, DSA review needed, both workstreams, or neither. Do not write DSA obligations into the MSR file without DSA grounding.

Check whether the matter already has a product-compliance anchor, such as Article 4, a customs hold, or a corrective-action request, before assigning the legal owner.

If the only unresolved point is whether a service provider must manage the listing, moderation, or removal process, that is a DSA-style question and should stay out of the MSR-only lane.

Use the product record to decide ownership first; use the platform record only for the separate service-governance review.

When a product offer, importer, fulfilment provider, or customs event is present, route the issue into MSR first and keep the product file complete before looking at platform governance.

When the dispute is only about the platform's own rules, internal processes, or intermediary duties, send it to a separate DSA review and do not force an MSR label onto it.

The cleanest split is product facts on one side and service-governance questions on the other; keep those records separate unless both are genuinely in play.