---
title: "How to answer privacy, GDPR and security questionnaires for marketplace apps"
description: "Every app marketplace asks what data the app touches, where it goes, who else processes it and what protects it. We answer every form from one data map per app, back each Yes with a public page or a contract, and treat a No that blocks approval as a reason to build, not to reword."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/privacy-gdpr-security-questionnaires-marketplace-apps/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: Apps / Compliance
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/confidentialitate-gdpr-chestionare-securitate-aplicatii/
---

# How to answer privacy, GDPR and security questionnaires for marketplace apps

*Every app marketplace asks what data the app touches, where it goes, who else processes it and what protects it. We answer every form from one data map per app, back each Yes with a public page or a contract, and treat a No that blocks approval as a reason to build, not to reword.*

> Apps · Compliance · 2026-10-11 · https://goingstellar.ro/methods/privacy-gdpr-security-questionnaires-marketplace-apps/

## Key points

- A marketplace privacy or security questionnaire can only be answered correctly from a per-app data map built from the code: requested scopes, stored data and every outbound request.
- GDPR Article 28 requires a data processing agreement between the customer as controller and the app vendor as processor, and a self-executing DPA incorporated into the terms of service takes effect on install without a signature.
- On Shopify, an app that stores a customer's name, email, phone or address is Level 2 protected customer data, and encryption at rest is a requirement, not an option.
- On Google Workspace, renaming the OAuth consent screen resets branding verification, and a verified branding result expires after 7 days unless it is published.
- A No that blocks marketplace approval is a reason to build the missing control, not to reword the answer.

## What the questionnaires are actually asking

To answer a marketplace privacy or security questionnaire, first write down for each app what end-user data it reads, where it stores that data, and what leaves the platform and to whom. Then answer every form from that one record and publish the documents it implies: a privacy policy, a security page and, if personal data reaches you, a data processing agreement. The forms differ by platform, but all of them test whether your declarations match what the code does.

A **data processing agreement** (DPA) is the contract that GDPR Article 28 requires between a *controller*, the customer who decides why personal data is processed, and a *processor*, the vendor who processes it on the customer's behalf. Without one the customer is in breach, so an EU buyer's legal team will not approve an install without it.

## Step one: a data map per app, sorted into groups

**1. Map what the code does, not what you remember.** For each app we list the scopes it requests, what it stores and where, and every outbound request, taken from the manifest and the code. A logo URL in a manifest is an external request, and a server that caches to disk stores data.

**2. Sort the apps into groups that share an answer set.** Our Forge apps fall into three groups: apps that store nothing and send nothing out, apps that store data only in the platform's own storage, and AI apps that send the user's prompt to a model provider. The AI group answers Yes to processing end-user data outside the platform, because a prompt a user types is end-user content; redefining it to get a cleaner form would be dishonest.

**3. Name the processing chain.** The customer is the controller, our company is the processor, and the platform and the AI model provider are sub-processors. Transfers outside the European Economic Area (EEA) are covered by the model provider's DPA, which incorporates the EU Standard Contractual Clauses (Module 2, Commission Implementing Decision (EU) 2021/914) into its commercial terms. That existing contract is what makes a Yes to the transfer question true.

## A self-executing DPA for every app

We publish one DPA page per app, in two variants: the AI apps name the model provider as a sub-processor; the apps with no outbound traffic state that no personal data reaches us at all. Each DPA is *self-executing*: it is incorporated into the app's terms of service and takes effect on install, with no signature, plus an offer to counter-sign on request.

A DPA is a list of obligations, so we wrote only ones we can keep: process data only on the customer's documented instructions; notify a personal data breach within 48 hours of becoming aware of it; delete or return data within 30 days of uninstall or a written request; give 30 days' notice before changing a sub-processor, with a right to object; accept an audit at most once a year, at the customer's cost; and assist with data-subject requests and with Articles 32 to 36.

The pages also say what we do not have: no SOC 2, no ISO 27001, no independent penetration test, and no data protection officer, which Article 37 does not require in our case. A reviewer reads a plain statement of absence more easily than vague wording.

## Atlassian: the Privacy & Security tab and two more forms

Each Atlassian Marketplace listing has a Privacy & Security tab. For an AI app, answering Yes to processing outside Atlassian opens four hidden required fields, each revealed only by the answer before it: the types of data accessed, privacy-enhancing techniques, whether data leaves the EEA, and which transfer mechanism applies. Declaring yourself a processor adds the end-user data types and whether you offer a DPA.

Once an app declares processing outside Atlassian, a public security policy link becomes required. Our security page per app states where the app runs, its scopes, its authorization model, what leaves Atlassian, and how to report a vulnerability, with a commitment to acknowledge within 2 business days and to fix, or give a plan, within 10.

Atlassian has three security forms: this tab, the Forge security questionnaire and a partner questionnaire about the company. The partner one opens from a button on an app's review ticket. Across the two questionnaires we answered 33 questions.

## Shopify: protected customer data levels

Shopify sorts apps by **protected customer data** (PCD). An app that uses customer data but not the identifying fields is Level 1; an app that stores a customer's name, email, phone or address is Level 2. Most of our Shopify apps are level 0 or 1 and passed easily; that precedent does not transfer to an app that stores a parcel recipient.

In the PCD request you first declare the fields you persist; over-declaring fails as surely as under-declaring, so check the model and every ingest path, including webhooks. Level 2 then brings 16 data-protection questions, which are legal attestations. Encryption at rest, encrypted backups and an incident-response policy are required, and a No means the app cannot ship.

For our Level 2 app the honest route was engineering. We encrypted the identifying columns at application level with AES-256-GCM and added *blind indexes*, keyed HMAC values of the normalised phone and email, so exact-match search still works; substring search on an encrypted name cannot work, so we removed it. Encrypted nightly backups, an accurate privacy page and a written incident-response policy made the other answers true. Selecting public distribution cannot be undone, and some of these checks only switch on after that click.

## Google Workspace: OAuth verification and branding

A Google Workspace add-on that requests any sensitive OAuth scope must pass OAuth verification, separate from the listing review, before the Marketplace approves it. Our order: scopes identical in three places (the Apps Script manifest, the Marketplace SDK configuration and the OAuth consent screen), then branding verified and published, then data-access verification, and only then the Marketplace submission.

Data-access verification asks for a written justification of up to 1000 characters per project and a YouTube link to a video showing each scope in use; the project owner does not see the unverified-app screen, so we film an install from the Marketplace with an outside account. Of our three verification rejections, two were about the privacy policy, not the code: it did not describe data-protection mechanisms, and it did not state with whom Google user data is shared. Naming the third party in passing was not enough; reviewers look for a dedicated section that names the recipient, says what is sent and excludes everyone else.

Branding verification is separate and fragile. Renaming the consent screen silently resets it; a verified result is not shown to users until you publish it, and it expires after 7 days if you do not. One logo of 15 was rejected because a generic motif did not identify our brand; a glyph that names the app's job passed first time. An audit also found 5 of 11 live add-ons with no logo on the consent screen, a rejection waiting for the next review.

One consent trap reached users: our authorization prompt supplied its own URL with no account hint, so people signed into several Google accounts landed on a page inviting them to request access to the script itself. In two days that produced 12 requests from 7 users across 5 apps. Letting Google supply the account-bound URL fixed it.

## Where we were wrong

Our first data-access justifications read well and contained statements the code contradicted: that nothing leaves the user's account, in an app that sends email; that nothing is stored, on a server that caches to disk. An adversarial audit that read the code as a reviewer would caught them. The final texts are now versioned and reused, never rewritten from memory.

We first answered No to offering a DPA on the Atlassian tab, because we did not have one. That was honest and it was a sales blocker; writing the DPA turned it into a Yes for 11 AI apps.

We treated a saved form as a submitted one: the Atlassian tab said the draft was saved, but no submit action existed while the apps were in review. We now also paste the answers into the review ticket. And we reported the account-hint fix as done when it existed only in local code; the add-ons stayed broken a day longer.

## Limits

This method keeps declarations consistent with the code. It is not legal advice, and an app handling health, financial or children's data needs a lawyer. It is not a certification either. Some behaviours we describe are quirks we observed, not documented rules, and the forms change.

If an app embeds a generative model, read the provider's terms on minors early: Google's terms for its generative AI services forbid use in a service directed at, or likely to be accessed by, people under 18, with no allow-listing even with parental consent.

## Checklist

**Before any form:** a data map per app from the code; the processing chain named; a privacy policy with sections on protection, sharing and AI training; a security page and, if personal data reaches you, a self-executing DPA.

**Per platform:** Atlassian tab answered by group, both questionnaires, answers pasted into the ticket; Shopify PCD fields matched to the model and webhooks, every required control real; Google scopes identical in three places, branding verified, published and re-verified after any rename.

## Questions and answers

### What is a self-executing DPA for a marketplace app?

A self-executing data processing agreement is a DPA incorporated into the app's terms of service that takes effect when the customer installs the app, with no signature. It still carries the GDPR Article 28 obligations: processing only on documented instructions, breach notification, deletion or return of data after uninstall, notice before changing sub-processors, and audit rights. Offering to counter-sign on request helps legal teams that prefer a signed copy.

### Which Shopify apps need encryption at rest for protected customer data?

Apps at Level 2, meaning apps that store a customer's name, email, phone number or address. For Level 2, Shopify's data-protection questions require encryption at rest, encrypted backups and an incident-response policy, and answering No blocks approval. Apps that use customer data without those identifying fields are Level 1. Check what the database and the webhooks actually store before you declare a level.

### Why did Google reject my Workspace add-on for missing OAuth verification?

Because the add-on requests at least one sensitive or restricted OAuth scope and has not passed OAuth verification, which is separate from the Marketplace listing review. Make the scopes identical in the Apps Script manifest, the Marketplace SDK and the consent screen, verify and publish the branding, submit data-access verification with a written justification and a YouTube video, and only then submit to the Marketplace.

### Why is my Google OAuth branding no longer verified?

Any change to the OAuth consent screen configuration, including a rename, resets branding verification, and Google sends no email about it; the status shows only in the Verification Center. A verified branding result must also be published separately, and it expires after 7 days if it is not. Re-verify and publish the branding after every consent-screen change.

### What does Atlassian's Privacy & Security tab ask an AI app?

If an app sends end-user data, such as a prompt the user types, outside Atlassian, answering Yes opens hidden required fields: the types of data accessed, privacy-enhancing techniques, whether data leaves the EEA, and which transfer mechanism covers it. Declaring yourself a processor adds the end-user data types and whether you offer a DPA, and a public security policy link becomes required.

## How to cite

**Cite this as:** Going Stellar (2026). *How to answer privacy, GDPR and security questionnaires for marketplace apps*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/privacy-gdpr-security-questionnaires-marketplace-apps/

```bibtex
@misc{goingstellar2026privacy,
  title  = {How to answer privacy, GDPR and security questionnaires for marketplace apps},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/privacy-gdpr-security-questionnaires-marketplace-apps/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/privacy-gdpr-security-questionnaires-marketplace-apps/
- Same article in Romanian: https://goingstellar.ro/ro/metode/confidentialitate-gdpr-chestionare-securitate-aplicatii/