Marketplace seller software data protection checklist

Set the service boundary

Set the review boundary around the seller, marketplace account, software service and any managed provider. Describe the product and order activity being assessed, so the record stays focused on the service in use rather than becoming a broad diagram of marketplace operations.

Mark where the seller activity ends and marketplace or provider activity begins. Use the journey through the service, not a generic workflow label, to make that boundary clear. The service standards offer a related way to describe duties and service limits.

Inspect device entry points

List cookies, pixels, SDKs, local-storage items, device identifiers and similar operations, including those supplied through a marketplace widget or support service. For each, record its purpose, duration, third party and whether it runs before the user has made a choice.

Keep the consent record and choice status alongside the inventory, then check the ICO guidance against PECR and UK GDPR requirements. A marketplace or payment permission does not establish consent for unrelated tracking. Record which technologies are present rather than assuming an embedded tool is harmless.

Give each purpose its own record

Separate order handling, account administration, support, security telemetry and analytics instead of describing them as one general use. That distinction makes it easier to identify the seller activity involved and to see where supporting evidence, review or a decision is still missing.

For each purpose, record the people affected, fields used, data source, collection point, lawful basis, owner, evidence version and recheck trigger. Include the retention period and deletion outcome. The quality checklist can help organise evidence IDs and an exit test.

Attribute decisions to each party

Work out who determines the purpose and essential means of each activity, who acts only on processing instructions, and whether a provider uses information independently. Consider the facts for each activity rather than assuming one role describes every service function. Record whether joint controllers are relevant to the arrangement.

For processor work, compare the terms with the actual service. Check instructions, confidentiality, security, subprocessors, rights assistance, audit and end-of-contract handling. The contract review and supplier evidence help test whether documents match the provider practice being assessed.

Trace recipients and locations

Follow information to recipients, remote access points and processing locations, and keep the evidence for each transfer with the relevant purpose. A general service description may not answer the question for a particular flow, so record the transfer evidence that supports the assessment.

For storefront analytics, include device identifiers, consent status and any transfer evidence, such as a UK IDTA or UK Addendum to the EU SCCs. Note the provider contact or representative for follow-up where the service record identifies one. Do not treat an overview of the service as proof that every data path has been checked.

Set the review threshold and data lifetime

Before use, screen whether a DPIA is required for a tool, widget or analytics tag. Record the outcome and which purposes it covers. The screening should consider whether processing is likely to create high risk, including through large-scale monitoring, profiling, new technology or information about vulnerable people.

For each purpose, note the lawful basis, retention period and deletion outcome, including hard deletion, anonymisation or backup expiry where relevant. Check the UK rules guide alongside the DPIA decision and the linked data protection by design requirement.

Exercise the operational controls

Use synthetic records to test minimum permissions, support access, logs, correction, rights routing, export, account removal and deletion. Give each test a named owner and retain its result as evidence. NCSC SaaS security guidance can inform checks on privileged access, monitoring and recovery, but does not certify a particular configuration.

Route rights requests to a named person and dated log, and record the applicable response timing. Set out an incident owner, containment route, incident route and evidence-preservation steps, including how a notifiable personal data breach is reported within the required time. The operations guide and risk scenarios can help organise these tests.

Apply the release gate

Check whether ICO registration and the data protection fee are current if the seller is a controller.

Keep the review grounded in the UK GDPR, PECR, the Data Protection Act 2018 and the Data (Use and Access) Act 2025. Record which guidance was checked so the evidence set shows what informed the decision.

Keep production disabled if the role, purpose, transfer, access path, retention period or deletion outcome is unknown. A completed map is not a compliance guarantee. Base release on the DPIA decision, test evidence, incident route and fee check, with a named owner and recheck trigger recorded for the evidence set.