Vendor-role registers, subprocessors, and SDK privacy notices for commerce apps

A subprocessor is a processor engaged by another processor, so most vendors you appoint directly, such as a cloud host, an analytics provider, or an app builder, are your processors, not subprocessors. A commerce app therefore needs a vendor-role register covering the whole stack, plus subprocessor lists for the processor chains inside it. The distinction decides contracts, authorisations, and disclosures.

This guide separates the four documents, explains how to assess a vendor's real role, and covers SDK disclosures, transfers, and store labels. It supports privacy and consent for e-commerce mobile apps.

Short answer. Build a vendor-role register for the full stack. Record every vendor's data flow, purpose, legal role, location, contract, and deletion route. Maintain or obtain subprocessor lists for the processor chains inside it. Use the register to create your privacy notice, App Store and Play labels, and consent screen. Do not copy the register into each one.

Scope, and what this is not. This is practical guidance, not legal advice. A vendor's legal role and the right transfer mechanism depend on your specific data flows and contracts and they change. Work the analysis with counsel and verify current platform and regulator requirements at the source before you rely on it.

Four artifacts, four audiences

Keep these as separate documents because they serve different readers and purposes:

The register is the internal source of truth. The other three come from it, but each has its own audience and rules. Common mistakes include publishing the internal register as a privacy notice or calling it a subprocessor list.

The role question comes first, and reality decides it

Before you list a vendor, work out its legal role. The label changes your obligations. Treat these commerce examples as starting points for an assessment, not settled classifications:

Two points matter more than the table. First, reality determines the role, not the contract label. A DPA cannot make a company your processor if it independently decides why and how to use data, or reuses data for its own purposes. Ask who decides why and how the data is processed. Advertising and measurement SDKs deserve particular scrutiny because the app builder, brand, analytics vendor, and ad platform can have different roles in different flows.

Second, a joint-controller relationship carries its own requirement. Under GDPR Article 26, joint controllers must allocate their respective responsibilities transparently through an arrangement, and the essence of that arrangement has to be made available to data subjects. So "we and the platform are joint controllers" is the start of an obligation, not a box ticked. Getting these roles right is also what makes deletion routable, as our data-mapping guidance describes.

Recommended vendor-role register fields

Keep the register internal and detailed enough to support counsel, deletion requests, and a regulator. These are operational fields, not a mandated public format:

• Legal entity name (the actual contracting entity).
• Service and processing purpose.
• Categories of data involved.
• Role: controller, processor, subprocessor, joint controller, or independent controller.
• Contracting entity, hosting locations, and remote-access locations (processing location alone is rarely enough).
• Onward recipients the vendor shares with, and the relevant transfer analysis.
• Contract reference (the DPA or other agreement), held internally, since a DPA is usually a confidential commercial contract, not something to link publicly.
• Date added, status, and owner.

Put the change-notice process in the document that matches its audience. Article 28 notices go to a processor's controllers. Privacy notices go to consumers. Do not add that process to every vendor row.

The typical commerce-app vendor stack

Commerce app stacks are often longer than expected, and roles vary. Personal data may reach:

• Cloud hosting and database infrastructure
• Content delivery network
• Authentication provider
• Error monitoring and crash reporting
• Product analytics
• Push-delivery infrastructure
• Customer-support platform
• Email and SMS provider
• Data warehouse
• Attribution and advertising SDKs
• Shopify and checkout integrations
• Apple and Google services

Some are clearly your processors. Others, especially the advertising, payment, and app-store entries, may act under a different role for some or all of what they do. Walk the list vendor by vendor and assign the role deliberately.

What subprocessor lists are

A subprocessor list tells a processor's controllers which suppliers that processor uses. If you are the brand, the relevant lists are those your processors publish or provide, covering their own suppliers. Maintain your own list only when you act as a processor for someone else.

The mechanism behind it is contractual, not a consumer feature. Under GDPR Article 28, where a controller has given a processor general authorisation to appoint subprocessors, the processor must inform the controller of intended additions or replacements and give the controller a chance to object. That is a duty a processor owes its controller. It is not a right that consumers hold, and a public "we updated our vendors" page does not discharge it. Keep the two separate: the Article 28 notice-and-objection runs up the processor chain; consumer transparency runs through your privacy notice.

What the privacy notice exposes (and what it does not)

The privacy notice is a consumer document, so it discloses what customers need, not the whole internal register. A privacy notice generally sets out the purposes, the categories of data, the recipients or categories of recipients, the customer's rights, and transfers where required. Note "recipients or categories of recipients": you are often not required to name every legal entity in your register in the public notice, and you generally do not publish confidential DPAs. Decide deliberately what the notice names versus categorises, and keep it consistent with the register behind it. The customer-facing controls that this notice points to are covered in the privacy-center section of our privacy and consent guide.

International transfers

Treat transfers as a legal test, not a map. "The data is hosted abroad" is not an analysis. For EEA or UK personal data, ask whether the arrangement is a restricted international transfer and, if so, which current mechanism applies. It might be an adequacy decision, Standard Contractual Clauses, the UK's International Data Transfer Agreement or addendum, or a certified framework such as the EU-US Data Privacy Framework. Since Schrems II, a mechanism alone may not be enough. You may also need a transfer risk assessment.

What decides it is the actual flow, not just where a server sits: the contracting entities, remote support access from other countries, onward transfers, and who is exporter and importer. Record the analysis per vendor, and do not state a specific vendor's mechanism as fixed, because vendors change entities, regions, and frameworks. Confirm the current position with counsel.

DPAs and contracts

The role you assigned determines the contract you need. Where a vendor is your processor, GDPR requires a data processing agreement with the Article 28 terms (processing only on your instructions, confidentiality, security, subprocessor rules, deletion or return at the end, and audit support). Where a vendor is a joint controller, you need an Article 26 arrangement that allocates responsibilities and whose essence is available to data subjects. Where a vendor is an independent controller, you are not instructing it, so a processor-style DPA is the wrong instrument, and you should understand its own terms instead. Matching the contract to the role is part of getting the role right.

Audit SDK disclosures, do not rely on a feature list

Third-party SDKs can collect data you are responsible for. "We only enabled these features" does not tell you what to disclose. An embedded SDK can auto-initialise, collect diagnostics, request permissions, or change behaviour in an update even when its customer-facing feature is off. Audit what the built app does: the SDK version and configuration, permissions and APIs, network calls and endpoints, and the vendor's documentation.

Capture the SDK-specific detail in the register, because it is what the store forms and consent screen draw on:

• SDK name and vendor, and version
• Owner on your side
• Auto-start / default behaviour (does it initialise before consent?)
• Permissions and API access it requests
• Data sent off device, and to which endpoints
• Consent dependency (does it wait for a consent signal?)
• Feature flag or configuration that governs it
• Apple and Play disclosure mapping for the data it handles

On Apple's privacy manifests specifically: they are not a blanket "every SDK needs a manifest" rule in the simple sense. Apple requires privacy manifests covering an app's use of certain required-reason APIs and its data collection, with specific requirements for a set of commonly used third-party SDKs, and manifests are not a substitute for answering the App Store privacy questions accurately. Because an added SDK can change your disclosures and, where it performs cross-company tracking, trigger an ATT prompt, the SDK inventory and the consent design are the same conversation, covered in App Tracking Transparency: when an e-commerce app needs ATT and how to ask.

Apple and Google need separate store-disclosure mapping

Do not assume one register auto-populates both stores, because Apple and Google use materially different definitions and taxonomies. The register feeds the store labels, but a mapping step, with an owner and sign-off, sits between them:

• Apple's App Store privacy details ask for data types, the use purpose, whether data is linked to the user's identity, and whether it is used for Apple-defined tracking.
• Google Play's Data safety section asks for collection and sharing under its own definitions, purposes, whether collection is required or optional, and app-wide security and deletion declarations. Google notes its taxonomy can differ materially from another store's, and that the declaration is global to the app package: if any distributed version or region collects or shares data, it generally belongs in the declaration.

Give the disclosure mapping a named owner. Test it against the built binary and keep it aligned with the listing, using how to fill in your app store listing without getting rejected.

Keep it current, in the right artifact

Each document needs maintenance. Update the vendor-role register when you add, remove, or change a vendor, then update the affected outputs. When you act as a processor, honour the Article 28 notice-and-objection duty to controllers. When consumer-facing practices change, update the privacy notice and give the notice required by the relevant law. There is no universal consumer right to subprocessor-change alerts.

A vendor checklist

Before you ship, confirm:

1. A vendor-role register covering the whole stack, including vendors inside SDKs.
2. A role assessed for each, against the actual flow and contract, with reality (not the label) deciding.
3. Subprocessor lists obtained from your processors, and maintained by you only where you act as a processor.
4. The right contract per role: Article 28 DPA for processors, an Article 26 arrangement for joint controllers, and an understanding of independent controllers' terms.
5. A transfer analysis per vendor for EEA/UK data, with a mechanism and assessment where the arrangement is a restricted transfer.
6. An SDK audit of the built binary, with the SDK-specific register fields filled in.
7. A store-disclosure mapping for Apple and Google, with an owner and sign-off.
8. A privacy notice that discloses recipients or categories, rights, and transfers, consistent with the register.
9. A change process that updates the right artifact for the right audience.

How NAPPS helps

NAPPS is one vendor in this picture. It can document its own role and services, but it cannot make your legal decisions.

Start with its role, directionally: if you are the controller and you directly appoint NAPPS to process your app's customer data, NAPPS would typically be your processor. It is a subprocessor only within a relevant processor chain, where another processor engages it. Which applies to you belongs in your assessment and the contract, not a blanket label. Two things to ask NAPPS for and verify against current, public materials rather than take on trust: a data processing agreement, and its own subprocessor list for the infrastructure behind the app, which covers NAPPS's own infrastructure and not your analytics, advertising, support, and other vendors. And the SDK discipline above applies here too: what you disclose is driven by what the built app actually does, including anything that auto-initialises, not only the features you switched on. What NAPPS does not do is decide any vendor's role, choose transfer mechanisms, or write your privacy notice. For how the register connects to deletion, see our guidance on retention and deletion; for the wider launch picture, how to turn a Shopify store into a mobile app (2026).

Straight from the source

These change, so check current versions:

• Europe: the GDPR text (processors and DPAs under Article 28, joint controllers under Article 26, transfers under Chapter V) and EDPB guidance on Standard Contractual Clauses and transfer assessments.
• Apple: the App privacy details requirements and privacy manifest and required-reason API rules for apps and listed third-party SDKs.
• Google: the Play Data safety section requirements.

The bottom line

Build a vendor-role register for the whole stack. Assess each vendor by what it actually does, not what its contract calls it. Keep subprocessor lists, the privacy notice, and store-disclosure mapping separate. Then analyse transfers, match contracts to roles, audit the built app's SDKs, and update the right document when something changes. That leaves you with a usable vendor map, not a logo wall.

If you are planning a Shopify app and want the SDK disclosures, store privacy labels, and vendor documentation handled cleanly from the start, book a 20-minute call with the NAPPS team and we'll show you how it comes together in a native app before you build.