Shopify Partner Governance is not one document. It is a set of obligations spread across the Partner Program Agreement, the API License and Terms of Use, and the App Store requirements, and what they demand of you depends mostly on two things: whether your app is public or custom, and which customer data fields it touches. Shopify does not require a penetration test to list an app. It does require mandatory privacy webhooks from every listed app, tiered controls on protected customer data, and a 24 hour breach notification. Independent testing is optional under the published rules and useful for reasons set out below.
We went and read the documents on 2026-08-21 and quoted them. Where something is our reading rather than Shopify’s words, it says so.
What Partner Governance actually is, and who it applies to
Start with an honest definitional point, because it saves you chasing a document that does not exist. Shopify does not publish anything called Partner Governance. We could not find the phrase used as a defined term anywhere in its developer documentation. It is a useful label for a real set of obligations, but if a vendor or consultant quotes you a Partner Governance control number or tier, ask which document it came from.
The obligations live in four places:
| Document | What it governs | Who it binds |
|---|---|---|
| Shopify Partner Program Agreement | Your relationship with Shopify as a Partner, including breach notification | Every Partner |
| Shopify API License and Terms of Use | How your app uses the API. Audit rights, suspension rights, security obligations | Every app using the Shopify API |
| App Store requirements checklist | Whether a public app gets listed | Public apps |
| Protected customer data requirements | Which customer data your app may access, and the controls that come with it | Any app requesting customer data |
Public app or custom app decides most of it
This is the fork that determines how much of the above lands on you. From Shopify’s distribution documentation:
| Public app | Custom app | |
|---|---|---|
| Definition | ”can be installed on multiple Shopify stores" | "installed on a single Shopify store, on multiple stores that belong to the same Plus organization or any transfer-disabled development stores” |
| Shopify approval | ”Approval required: Yes" | "Approval required: No” |
| App Store listing | Required | Not applicable |
| Protected customer data Level 1 | Requires review | Always available |
| Protected customer data Level 2 | Requires review | Always available. Varies by plan for admin-created custom apps |
| Billing API | Available | Cannot be used to charge merchants |
The trap in that table is the bottom-left half. A custom app skips app review and gets protected customer data access without a review. What it does not skip is the API License and Terms of Use. The 24 hour breach notification duty, the security configuration obligation, Shopify’s audit rights and its right to suspend API access apply to a custom app exactly as they apply to a public one.
So a custom app can hold Level 2 customer data, name, address, email and phone, with nobody having reviewed it. That is less scrutiny carrying the same risk, and it is our reading rather than a Shopify statement, but the documents support it plainly enough.
How you actually list an app
Shopify publishes the status flow. It does not publish a timeline, and we would rather say so than repeat a number we cannot source.
From the app review process documentation, a public app moves through these statuses:
- Draft. The initial status when a public app is created.
- Submitted. After you click Submit your app.
- Paused. Conditional. “If your app doesn’t meet core requirements…your app moves to the Paused status and then you’ll receive an email that outlines required changes.”
- Reviewed. Conditional. “If your app requires additional fixes…it moves to the Reviewed status. You’ll receive an email that outlines the next steps.”
- Published. Approved and listed.
Resubmission is by clicking Submit fixes in the status banner. No cap on resubmissions is published.
Plan against round trips, not against a date. Every Paused or Reviewed status is a round trip, and each one is triggered by something that was knowable before you submitted. The checklist below is where most of them come from.
What has to be ready
The App Store requirements checklist organises requirements into categories, of which two are directly security and privacy: Security and merchant risk, and Data and user privacy. The others cover prohibited configurations, installation and setup, functionality and quality, app performance, the listing itself, support, and a set of category-specific requirements.
Two requirements from those sections are worth pulling out because they are hard gates rather than guidance:
- Supported APIs only. “Your app should use supported APIs only. Apps using APIs that will be deprecated within 90 days can’t be submitted.” A dependency audit against the deprecation calendar is a cheap pre-submission check.
- A privacy policy in your listing. Shopify frames this as building transparency with merchants.
And the framing Shopify puts on the security section, which is the whole posture in one sentence: “Before you submit your app, make sure it’s secure so the merchants who use it won’t be at risk.”
The security and data requirements
This is the substance, and there is more of it published than the reinstatement path would suggest.
Mandatory privacy webhooks, and the scope catches people out
From Shopify’s privacy law compliance documentation:
“Any app that you distribute through the Shopify App Store must respond to data subject requests, regardless of whether the app collects personal data.”
Read the last clause twice. An app that touches no customer data at all still has to implement all three webhooks. This is one of the most common listing rejections and one of the cheapest to avoid.
| Webhook topic | What it requires | Timing |
|---|---|---|
customers/data_request | Provide stored customer data to the store owner when a customer requests it | Complete within 30 days of receiving the request |
customers/redact | Delete or redact customer data | Within 30 days of receiving the request |
shop/redact | Erase all store data from your database after the store owner uninstalls your app | Sent 48 hours after uninstall |
The 30 day window carries an exception where you are legally required to retain the data. Shopify’s documentation states that apps are rejected if they do not provide webhook URLs or respond as required before submission for app review.
Protected customer data: the closest thing Shopify has to a control list
Shopify defines protected customer data as any data that directly relates to a customer or prospective customer, as represented in specific API types and resources. Queries that do not refer to a single customer, such as product queries, are excluded.
Four fields are singled out as protected customer fields, each requested individually: name (first and last), address (line 1, line 2, geolocation, and zip codes in billing and shipping), email, and phone.
Access sits at three levels:
| Level | Definition | Public app | Custom app |
|---|---|---|---|
| Level 0 | No customer data | No action required | No action required |
| Level 1 | ”Customer data excluding name, address, phone, and email fields” | Requires review | Always available |
| Level 2 | ”Customer data including name, address, phone, or email fields” | Requires review | Always available. Admin-created custom apps vary by plan |
Level 1 requirements, all nine, verbatim:
- “Process only the minimum personal data required to provide app functionality to merchants.”
- “Inform merchants what personal data you process and your reason for processing it.”
- “Limit your processing of personal data to the stated purposes.”
- “Where applicable, respect and apply customer consent decisions.”
- “Where applicable, respect and apply customer decisions to opt out of any data sharing such as a ‘data sale’ or similar concept under applicable laws or regulations.”
- “If you use personal data for automated decision-making and those decisions might have legal or significant effects, then you must allow customers to opt out.”
- “Make privacy and data protection agreements with your merchants.”
- “Apply retention periods to make sure that personal data isn’t kept for longer than needed.”
- “Encrypt data at rest and in transit.”
Level 2 requirements, all seven, on top of Level 1, verbatim:
- “Encrypt your data backups.”
- “Keep test and production data separate.”
- “Have a data loss prevention strategy.”
- “Limit staff access to protected customer data.”
- “Require strong passwords for staff accounts.”
- “Keep an access log to protected customer data.”
- “Implement a security incident response policy.”
Sixteen controls in total. Note what is in them and what is not. They are organisational and architectural controls: encryption, separation, access limitation, logging, retention, incident response policy. There is no testing control. Nothing in either list asks you to verify that the application actually resists attack.
That is a real gap, and worth naming rather than papering over. Encrypting data at rest does not help if an access control flaw lets one merchant read another merchant’s orders. The Level 1 and Level 2 lists would both be satisfied by an application with that flaw in it.
Requesting access
From the Partner Dashboard, per Shopify’s documentation: go to Apps and select your app, click API access requests in the sidebar, find Protected customer data access and click Request access, select Protected customer data and give your reasons, then if needed select the specific fields and give reasons for each, complete Data protection details, and submit the app for review. You need to have selected a distribution method for the app first.
The per-field reasoning is the part to take seriously. You justify each of name, address, email and phone separately. Requesting a field you do not use is a self-inflicted problem, for reasons the next section makes clear.
Data protection reviews
Shopify describes this as a detailed review of your practices:
“During this review, you’ll need to provide evidence that your app and your practices meet the protected customer data requirements.”
Shopify publishes the selection criteria, and they are not random. Reviews “likely focus on apps that have: High number of merchant installs, High volume of customer records, More protected customer fields approved, Long retention of personal data.”
Three of those four are choices you make. You cannot help succeeding and gaining installs. You can absolutely control how many protected fields you request, how many customer records you hold, and how long you keep them. Data minimisation and retention limits are already Level 1 requirements; they also happen to lower your odds of a review and shrink what you have to evidence if one comes.
On process, Shopify says only that if your app is selected it will contact you with instructions. No timeline, no evidence format, no template is published.
The obligations that never switch off
These come from the API License and Terms of Use and apply to public and custom apps alike, listed or not.
Breach notification, 24 hours. Section 6.2.10, with identical wording in the Partner Program Agreement:
“notify Shopify of any actual or suspected breach or compromise of Merchant Data (a “Data Breach”) immediately upon, but no later than twenty-four (24) hours of, becoming aware of such occurrence”
The trigger is actual or suspected, and becoming aware, not confirming. A suspicion starts the clock. The same clause requires you to promptly remedy the breach, investigate the incident, take reasonable actions to mitigate future anticipated harm, and regularly communicate the progress of the investigation to Shopify. That last one is continuous. Going quiet while you fix things is itself a problem.
Security configuration. Section 7.2 requires that your systems “must be properly configured to Internet industry standards so as to securely operate your Application and protect against unauthorized access to, disclosure or use of any information you receive from Shopify, including Merchant Data.” Deliberately open ended, and the only place in the published rules where the technical security of your app is addressed at all.
Audit and proof. Section 8 reserves Shopify’s right to “audit, or to appoint an independent auditor under appropriate non-disclosure conditions to audit Developer’s App, systems and records to confirm Developer’s compliance with the Terms”, and states: “If requested, you must provide us with proof that your Application complies with these Terms.”
Monitoring and suspension. Section 7.1: Shopify “may suspend access to the Shopify API by you or your Application without notice if we reasonably believe that you are in violation of the Terms”, and separately monitors API use and may access applications “to identify security issues”. Section 13.1 confirms access “may be terminated or suspended by Shopify at any time and at Shopify’s sole discretion”.
Ongoing, not one-off. The Built for Shopify documentation confirms apps must uphold the API License and Terms of Use on an ongoing basis. Passing review once does not settle anything.
Where independent security testing fits
Here is the honest answer, and it is not the one a security firm is expected to give.
Shopify does not require a penetration test at any tier. Not to list a public app, not to reach Level 2 protected customer data, not to keep a listing. We checked the App Store requirements checklist, both protected customer data control lists, the app review process page and the API Terms. None of them mention penetration testing, vulnerability testing or a third-party assessment.
That is a genuine difference from neighbouring platform programmes, and worth knowing if you are working across several. Microsoft 365 Certification states that penetration testing is mandatory and that the report cannot be scanner output. The Amazon SP-API Data Protection Policy has its own published expectations. Shopify publishes no equivalent. If your compliance plan assumes parity across marketplaces, it is wrong in Shopify’s direction.
So when does testing actually matter here? Four situations, and only the last is urgent.
1. When you have to produce evidence and have none. Section 8 says proof of compliance on request. A Level 2 data protection review says “provide evidence that your app and your practices meet the protected customer data requirements”. Neither names a pentest. But if you are selected and asked how you know your access controls hold, a policy document is a weaker answer than a test result, and you will be assembling the answer under a deadline rather than ahead of one.
2. When “Internet industry standards” has to mean something. Section 7.2 is the only technical security obligation in the published rules, and it is open ended by design. Testing is how you find out whether you meet it. Nobody grades you on this until something goes wrong, at which point it is graded retrospectively.
3. When your buyers ask, and they are not Shopify. Merchant security questionnaires, enterprise procurement and investor diligence run on their own schedule and have nothing to do with Shopify’s requirements. This is the most common real reason app developers commission testing, in our experience, and it is worth separating from platform compliance so you scope it for the right audience.
4. After a security incident. Covered below.
Our position, stated as ours: if your only goal is getting listed, a penetration test is not on the checklist and we are not going to pretend otherwise. If your goal is not to be the app that gets selected for a data protection review and cannot produce evidence, or the app that discovers an access control flaw by being told about it, that is a different calculation and you should make it on those terms rather than on a compliance requirement that does not exist.
The gap in the sixteen controls is the substance of the argument. They cover how you store and handle data. They do not cover whether the application can be attacked.
Suspension and reinstatement
One branch of this, and the one with the least published detail.
A review can begin without any report from you, because Section 7.1 confirms Shopify monitors API use and may access applications to identify security issues. Suspension can happen without notice, at Shopify’s sole discretion.
What Shopify publishes about getting back: nothing we could find. No reinstatement control list, no evidence deadline, no document template, no defined process. We looked. It appears to be handled case by case and communicated privately to the affected partner.
So the single most useful thing you can do is ask your Shopify contact, in writing, what evidence they want. It costs an email and it is the only reliable source on your specific case. It beats every general recommendation on this page, including ours.
What we can describe honestly is the shape of what an independent assessment has to demonstrate, because that shape is set by the reader rather than by Shopify. Two documents usually travel together and they answer different questions:
| Incident report | Independent assessment | |
|---|---|---|
| Question | What happened | What is true now |
| Direction | Backward, one specific event | Forward, current attack surface |
| Source | Your logs, timeline, change history | Live testing of the running system |
| Who can write it | Only you. Nobody else has the history | An assessor independent of the build |
| What convinces | An honest timeline, including the gap between compromise and detection | Reproducible findings with evidence and a recomputable severity |
| Failure mode | Vague on dates, vague on data reached, silent on how it was found | A severity label with no proof behind it |
A reader takes the incident report to understand the fault, then takes the assessment to judge whether the rest of the application looks like the same fault waiting to happen elsewhere. Answering only the first question leaves the obvious second one open.
On independence. Shopify’s Section 8 reserves independence for its own appointed auditor. It does not, in any text we could find, require your assessor to be independent of your build team. So this is our reasoning, not a rule: an assessment written by the team that built the system and did not catch the original fault is being asked to grade its own work under deadline, and a reader outside your company has no way to weigh it. Separation is what makes the finding legible to someone who was not in your standups.
One point on the incident report. The pull under pressure is to minimise: shorten the exposure window, soften how it was found, leave out that a merchant reported it before your monitoring did. Do not. A discrepancy later discovered between your account and someone else’s telemetry teaches them something worse than the incident did. An honest detection gap with a named fix reads as a team that understands its own weakness.
And the thing nobody can sell you: Shopify decides. Section 13.1 puts it in one line. No security firm sits in that decision or can commit to its outcome.
One report, and what a Shopify engagement adds to it
Shopify specifies no report format, so the format is set by whoever ends up reading it: a data protection reviewer, an enterprise merchant’s security team, or your own engineers. That makes it worth stating exactly what our document contains and what changes with the plan, rather than leaving you to work out where the line falls after you have paid.
One findings schema, one core report, at every tier. Each finding carries a finding ID and title, the scope it belongs to and the affected endpoint, a severity band, a CVSS v3.1 score with the full vector string, a CWE identifier and a second where the weakness spans two classes, the OWASP category matched to the surface tested, a description, reproduction steps, evidence, business impact and a specific remediation. Each remediated finding carries a retest block: what was applied, how it was re-checked, what was observed, the result, and fresh evidence of the fixed state. Each report carries an executive summary, the scope and methodology, a findings summary, a severity distribution, an appendix, a disclaimer, and a named lead assessor with their credential.
A Startup plan buyer receives every one of those fields. There is no reduced edition of the report, and no finding detail printed for one buyer and withheld from another. The plans differ on how many scopes are tested, how many consulting hours come with the engagement, and the compliance layer below. They do not differ on the finding.
The compliance layer is the Growth plan. Per-finding mapping to SOC 2 Trust Services Criteria and ISO 27001:2022 Annex A controls, a compliance evidence package presenting those mappings as control-to-findings matrices, and a Letter of Attestation issued as a separate document after the retest, so it reflects the remediated state rather than the original findings. Where a reviewer needs evidence that an independent firm was engaged rather than an internal team, a Letter of Engagement is issued alongside it. That applies to Shopify Partner reviews and to Amazon SP-API Data Protection Policy submissions, which are the two places buyers ask us for it, and both letters sit on the Growth plan.
For a Shopify engagement, a protected customer data index. The same findings listed a second time against the Level 1 and Level 2 control lists quoted above, so a reviewer reads them in the order Shopify’s own requirements are written rather than the order your application is built.
Be clear about what that index cannot do, because this page has already made the point once. Those sixteen controls contain no testing requirement. An index against them shows where a finding touches a control you have committed to. It does not turn a penetration test into evidence of the controls themselves, most of which are organisational and are evidenced by your records, your policies and your access logs rather than by anything a tester can observe.
And the mapping does not change what was tested. It is a second index over the same findings, built for a reader working through a control list instead of an application. If you are not facing a review, you would never open it, and you should not be paying for it.
What to check with any vendor
Useful whether or not you hire us, and this is the section to read before signing anything with anyone.
1. Are you independent of whoever built and operates this app? If the assessor also built it, the assessment is doing half the job. An in-house or development agency assessment usually does not carry the weight this situation needs.
2. Will every finding have reproduction steps and evidence, or just a severity label? Ask to see a real redacted finding before you sign. Every serious firm has one.
3. Is severity a CVSS vector I can recompute, or an adjective? A vector string like AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N is checkable in thirty seconds. “High” is not. If the answer is “we use our own risk rating”, ask what it maps to.
4. Is a retest included, and is it a full updated report or a one-line note? This is where the money hides. A retest billed as a fresh engagement, or delivered as an email saying confirmed fixed, leaves you without the document you actually need. Ask what version the retest deliverable carries and what is in it.
5. Is the tester named, with a credential I can verify? A report signed by a company and nobody in particular says nothing about who did the work.
6. Can you turn this around inside my deadline, and will you put that in writing? Not “we will try”. A date, in the proposal.
7. Do you issue an attestation letter, and at what point in the sequence? If it is issued before the retest, it describes the broken state. Ask when.
8. Does your scope include multi-tenant access control between merchants? Specific to this platform and frequently missed. Most Shopify apps serve many merchants from one backend, so the highest-value flaw is usually one merchant reaching another merchant’s data. That is a business logic and authorisation test, not something a scanner finds.
9. Do you claim you can get my app listed, approved or reinstated? Nobody can. The fastest disqualifying question in the list. A vendor claiming platform outcomes, or quoting a success rate for them, is describing decisions that belong to Shopify.
Our longer general guides are how to evaluate a penetration testing firm and 5 questions to ask a pentest vendor before signing. On reading the output, how to read a VAPT report and what a good pentest report looks like.
What we do, and what we do not
We are Cybersecify, founder-led security testing for AI-first and API-first SaaS startups. Both founders are hands-on in every engagement.
What we do. Independent manual penetration testing of web applications and APIs, driven by methodology rather than scanner output: applicable OWASP Web Security Testing Guide v4.2 test cases, OWASP Top 10:2025, the OWASP API Security Top 10 2023, OWASP ASVS with stated levels, and the PTES lifecycle. Every finding carries a CWE and a CVSS v3.1 score with the full vector. Testing is led by an OSCP-certified co-founder named in the report with the certificate number. The retest is delivered as a v2.0 report superseding v1.0, carrying fresh evidence of the fixed state for each finding rather than a changed status column alone. A Letter of Attestation is issued as a separate document after the pentest and the retest, so it reflects the remediated state. Reports are written to be read by a third party, which is the constraint that matters when the reader is a platform reviewer or an enterprise merchant.
Engagements run 5 business days per scope. One scope is 5 business days, two are 10. On our Growth plan each additional scope adds 5 business days by default, so three scopes is 15 business days and four is 20. Parallel testing on request runs scopes 3 and 4 together and brings four scopes to 15. Five or more get a custom scoping proposal. A retest runs 1 to 3 business days and is included free within one month of the v1.0 report. What none of that tells you is total elapsed time, because the longest and least predictable step is your own remediation between the two reports, and no vendor can quote that for you.
What we do not do. We do not decide whether your app is listed or reinstated, we have no visibility into those decisions, and we will not tell you we can influence them. We do not implement your privacy webhooks or write your privacy policy; those are development work and they are on the published checklist, so do them regardless of who you hire for testing. We do not write your incident report, because the timeline, logs and change history are yours and only you can speak to them honestly. We can review a draft and say where a reader will push back, which is a smaller and different thing. We do not quote success rates on platform reviews. And we will not promise a clean report, because a tester who promises what they will find before testing has told you the finding was never the point.
Do this before talking to anyone, including us. Work through Shopify’s own checklist and the protected customer data requirements first. Implement the three webhooks. Audit your dependencies against the API deprecation calendar. Request only the customer fields you actually use. All of that is free, all of it is published, and all of it removes round trips that no vendor can remove for you.
If you want to see our report format before committing to anything, it is at sample report. If you would rather talk scope, contact us with your architecture rather than asking for a price. Published plan pricing is on the pricing page.
Sources
Every Shopify document below was fetched and quoted on 2026-08-21.
- Shopify API License and Terms of Use. Sections 6.2.10, 7.1, 7.2, 8 and 13.1
- Shopify Partner Program Agreement. Data Breach notification and post-incident obligations
- Protected customer data. Levels 0, 1 and 2, protected fields, access request steps, data protection reviews, full Level 1 and Level 2 requirement lists
- App distribution. Public and custom app definitions, approval requirements, Billing API limitation
- App review process. Draft, Submitted, Paused, Reviewed and Published statuses, resubmission
- App Store requirements checklist. Requirement categories, supported APIs rule, privacy policy, security framing
- Privacy law compliance. The three mandatory webhook topics, 30 day window, 48 hour shop/redact timing, rejection consequence
- Built for Shopify. Ongoing obligation to uphold the API License and Terms of Use
Adjacent platform programmes that do publish testing requirements, for comparison: Microsoft 365 Certification pentest requirements and the Amazon SP-API Data Protection Policy pentest. If an incident touches personal data of users in India, the DPDP Act data breach response playbook covers a separate notification duty that Shopify’s 24 hour clock does not discharge.