Shopify Partner Security Testing
Start with the part most vendors will not tell you: Shopify does not require a penetration test to list an app. Not to list a public app, not to reach Level 2 protected customer data. The sixteen controls contain no testing requirement. What Shopify does have is the right to ask you to prove compliance, and the right to suspend your app without notice where it reasonably believes you are in breach. Those are the moments that bring teams here, and they are what this page is scoped against.
Three moments, and nothing in between
Because nothing is mandated, buying a test for a Shopify app on a schedule is hard to justify. These are the points where it stops being optional in practice.
Shopify asks you to prove it
Section 8 of the API Terms lets Shopify require proof that your app complies. Level 2 apps may be selected for a data protection review, where you must provide evidence that your app and your practices meet the protected customer data requirements. Shopify publishes no evidence format and no timeline, so what you hand over is your choice. A current independent test report is the strongest thing most teams can produce.
Your app is suspended and you want it back
Section 7.1 lets Shopify suspend API access without notice where it reasonably believes you are in violation of the Terms. There is no published reinstatement checklist, no evidence deadline and no template. What the terms do establish is Section 6.2.10’s duty to notify Shopify of an actual or suspected breach immediately and no later than twenty-four hours after becoming aware of it, a duty to remedy and investigate, a duty to keep communicating progress, and Section 8 proof on request. An independent assessment and a written incident report are the ordinary way to produce that proof.
You are about to request Level 2 and want to know what you are signing up to
Level 1 carries nine requirements and Level 2 adds seven on top. They are organisational and architectural: encryption, separation, access limitation, logging, retention, and an incident response policy. Knowing which ones your architecture already fails is cheaper before you request access than after a review starts.
What Shopify publishes, and what we test against it
Shopify publishes no control numbering of its own, so this table names the document and the section each requirement comes from. Everything in the left column was read from Shopify's own documents and is quoted or closely paraphrased. The right column is what we test or produce against it, and three rows say we do nothing, because three of these are not testing work at all.
| What Shopify publishes | What we test or produce |
|---|---|
| A penetration test Not required. Not to list a public app, not to reach Level 2 protected customer data, not to keep a listing. The App Store requirements checklist, both protected customer data control lists, the app review process page and the API License and Terms of Use mention penetration testing, vulnerability testing and third-party security assessment nowhere at all. Checked across all four documents | Nothing is owed to Shopify here, and we will not pretend otherwise. Anyone telling you Shopify mandates a pentest to get listed is wrong. The rows below are where testing actually earns its place. |
| Section 7.2: security configuration 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." This is the only place in the published rules where the technical security of your app is addressed at all, and it is open ended by design. API License and Terms of Use, Section 7.2 | The test itself. Applicable OWASP Web Security Testing Guide v4.2 test cases, OWASP Top 10:2025, the OWASP API Security Top 10 2023, OWASP ASVS with the level stated, and the PTES lifecycle. Multi-tenant authorisation between merchants is scoped explicitly, because most Shopify apps serve many merchants from one backend and one merchant reaching another merchant’s data is the highest-value flaw on the platform. That is a business logic and authorisation test, not something a scanner finds. |
| Section 8: audit, and proof on request Shopify reserves the 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." No format for that proof is published. API License and Terms of Use, Section 8 | A report written for someone who has never seen your architecture and will not ask a follow-up question: the scope tested, the dates, the methodology and standards followed, and the tester named with a verifiable credential. Per finding, a CWE, a CVSS v3.1 score with the full vector string so the rating can be recomputed, reproduction steps, evidence, business impact and a specific remediation. |
| Section 6.2.10: breach notification inside 24 hours You must "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", then 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. The trigger is suspicion and awareness, not confirmation. Identical wording appears in the Partner Program Agreement. API Terms Section 6.2.10, and the Partner Program Agreement | The incident report and the penetration test behind it, produced together on the timeline the platform asks for, plus the retest that closes the findings. The notification itself is yours to send inside the 24 hours and nothing we do changes that clock, which is why the honest sequence is notify first, engage us second. |
| Sections 7.1 and 13.1: monitoring, suspension, termination 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", 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". No reinstatement control list, evidence deadline or document template is published. API License and Terms of Use, Sections 7.1 and 13.1 | An independent assessment of the app in the state it is actually in, starting where the incident started, and verification of the fixed state once your engineers have remediated. Reinstatement is Shopify’s decision. We do not influence it, we have no visibility into it, and we do not quote a success rate for it. |
| Protected customer data, Level 1: nine requirements Data minimisation, telling merchants what you process and why, limiting processing to those stated purposes, respecting customer consent decisions, respecting opt-outs from data sharing, allowing opt-out of automated decision-making with legal or significant effects, making privacy and data protection agreements with your merchants, applying retention periods, and "Encrypt data at rest and in transit." Protected customer data requirements, Level 1 | Encryption in transit is testable and we test it. Encryption at rest and the eight requirements above it are organisational and contractual, evidenced by your records, policies and agreements rather than by anything a tester can observe. The control index shows where a finding touches one of them. It does not evidence the control. |
| Protected customer data, Level 2: seven more "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 across both levels, and not one of them is a testing control. Protected customer data requirements, Level 2 | Readiness work on the security incident response policy the seventh requirement asks for, where you do not already have one that survives reading. The other six sit with you. Knowing which ones your architecture already fails is cheaper before you request Level 2 access than after a review has started. |
| The Level 2 data protection review A detailed review of your practices, in which "you’ll need to provide evidence that your app and your practices meet the protected customer data requirements." 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." If selected, Shopify contacts you with instructions. No timeline and no evidence format is published. Protected customer data requirements, data protection reviews | The report, plus an index of the same findings against the sixteen Level 1 and Level 2 controls, so a reviewer reads them in the order Shopify’s own requirements are written rather than the order your application is built. Three of the four selection criteria are choices you make, so requesting only the fields you use and applying real retention limits lowers your exposure before any vendor is involved. |
| The three mandatory privacy webhooks "Any app that you distribute through the Shopify App Store must respond to data subject requests, regardless of whether the app collects personal data." The topics are customers/data_request, customers/redact and shop/redact. The first two must be completed within 30 days of the request, with an exception where you are legally required to retain the data; shop/redact is sent 48 hours after uninstall. Apps are rejected if they do not provide webhook URLs or respond as required before submission for review. Privacy law compliance documentation | Nothing. This is development work, it is on the published checklist, and you should do it regardless of who you hire for testing. It is one of the most common listing rejections and one of the cheapest to avoid. An app that touches no customer data at all still has to implement all three. |
| 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 privacy policy in your listing is required alongside it. App Store requirements checklist | Nothing. A dependency audit against the deprecation calendar is a cheap pre-submission check you can run yourself, and it removes a round trip no vendor can remove for you. |
Sources are listed at the foot of this page. The full reading, including what the documents leave open, is in our Shopify Partner security requirements guide. How an engagement runs is on the methodology page, and the surfaces themselves are web application and API testing.
What we can do about reinstatement, and what nobody can
We cannot get your app reinstated, and nor can anyone selling you that. Shopify decides. It publishes no reinstatement control list, no evidence deadline and no template. A vendor quoting a success rate for reinstatement is quoting a number for someone else's decision.
What the terms do call for is evidence, and that we can produce: an independent assessment of the app in the state it is in now, starting where the incident started, and the technical material behind a written incident report. We will review your draft report and tell you where a reader will push back.
We do deliver the incident response side of this. A platform opening a security incident review asks for an incident report and a penetration test on one timeline, and we produce both, with the retest that closes the findings. What we are not is a 24/7 on-call function sitting on a retainer. We are engaged after the incident, to assess it and evidence it.
We have done this before
We have done this before. A customer came to us with their app suspended. We assessed the application in the state it was actually in, produced the report and the supporting technical material their submission needed, and worked to the guidelines the platform had set rather than to a template of our own. That material is what they put in front of the reviewer. The app was reinstated.
The decision was Shopify's, as it always is. What we contributed was evidence: a current independent assessment, findings with reproduction steps, and verification of the fixed state once their engineers had done the work. We had no visibility into the decision and we are not telling you we influenced it. What we can tell you is that the work a reinstatement submission needs is work we do, to the platform's own guidelines. We do not quote success rates on platform reviews, and you should treat anyone who does as describing someone else's decision.
What you receive
- A penetration test report with every finding carrying a CVSS v3.1 and v4.0 score and vector string, a CWE identifier, reproduction steps, evidence, business impact and specific remediation.
- An index of the same findings against the sixteen Level 1 and Level 2 protected customer data controls, showing where each finding touches a control you have committed to.
- Readiness work on the security incident response policy that Level 2 control 7 requires, where you do not already have one that survives reading.
- For a suspended app: the incident report and the penetration test behind it, produced together on the timeline the platform asks for, plus the retest that closes the findings.
- A v2.0 report after the retest, superseding v1.0, with fresh evidence of the fixed state.
The control index shows where a finding touches a control you have committed to. Those sixteen controls carry no testing requirement, so it does not evidence the organisational controls themselves, and we will not present it as if it does.
Scope follows the moment, not a template
Shopify names no scope, so we will not invent one. The plan is the Compliance Plan at INR 1,79,999, which covers two scopes, with each further scope at INR 74,999. It is the Compliance Plan because the control index this page promises is per-finding control mapping, and that is a Compliance Plan deliverable, along with the Letter of Attestation. Most Shopify engagements come to the app and its API. A suspended app usually needs more, because the assessment has to start where the incident did.
| Engagement shape | Price and duration |
|---|---|
| Two scopes. Usually the app and its API together Compliance Plan | INR 1,79,999 · 12 business days |
| Each further scope on the Compliance Plan Scope addition | INR 74,999 · plus 6 business days |
| Retest, closing the findings Included in both plans | No charge · 1 to 3 business days |
Prices exclude taxes. A scope is six business days, five testing and one writing the report, so the report lands inside the window rather than after it. For larger estates we confirm the schedule when we scope it. The retest is free within one month of the v1.0 report, and sooner if your fixes land before that. What none of this tells you is total elapsed time, because the longest and least predictable step is your own remediation between the two reports. Full terms are on the pricing page.
Shopify Partner security questions
Does Shopify require a penetration test to list an app?
No. We went looking for that requirement and it is not there. We checked the App Store requirements checklist, the protected customer data requirements including the full Level 1 and Level 2 control lists, the app review process page, and the API License and Terms of Use. None of them mention penetration testing, vulnerability testing or a third-party security assessment. This is a real difference from neighbouring platform programmes: Microsoft 365 Certification states that penetration testing is mandatory, and Amazon SP-API requires an annual penetration test for restricted roles while saying nothing about who may perform it. Shopify publishes no equivalent, and anyone telling you Shopify mandates a pentest to get listed is wrong.
Then why would we buy a penetration test for a Shopify app?
Because of what Shopify can ask you for rather than what it requires up front. Section 7.2 of the API Terms requires your systems to be configured to Internet industry standards. Section 8 says that if requested you must provide proof that your app complies with the Terms. Level 2 apps may be selected for a data protection review where you must provide evidence that your practices meet the requirements. Shopify publishes no format for that evidence. Testing is one way to produce it, and it is the way that stands up when the reviewer is technical. It is not a named requirement and we will not pretend otherwise.
Our app has been suspended. Can you get it reinstated?
No, and neither can anyone else. Shopify decides reinstatement. Section 7.1 states that Shopify may suspend access without notice if it reasonably believes you are in violation, and Section 13.1 states access may be terminated or suspended at any time at Shopify’s sole discretion. Shopify publishes no reinstatement control list, no evidence deadline and no document template, and we could not find one. Any vendor who claims they can get your app reinstated, or quotes a success rate for it, is describing a decision that belongs to Shopify. What we can do is help you meet what Shopify asks for, working to their published guidelines: the assessment, the findings, the remediation guidance and the fixed-state verification a reinstatement submission needs. Not being able to promise the outcome is not the same as not being able to help with the work, and we have done it: a customer came to us with their app suspended, we worked to the platform’s own guidelines, and the assessment and reporting we delivered were what they put in front of the reviewer. The app was reinstated. The decision was Shopify’s, as it always is; we had no visibility into it and we are not claiming we influenced it. We do not quote success rates on platform reviews and you should treat anyone who does as describing someone else’s decision.
Do you do incident response?
Yes, for the case this page is about. When a platform opens a security incident review, it typically asks for an incident report and a penetration test together, on one timeline. We deliver both: the incident report, the VAPT behind it, and the retest that closes the findings. We have done it, and the platform accepted both documents. We also deliver the readiness work on the incident response policy that Level 2 control 7 requires. What we are not is a 24/7 on-call function: we are engaged after the incident to assess it and evidence it, not to sit on a retainer waiting for one. If you need someone in the room during a live breach, say so early and we will tell you honestly whether we are the right call.
What does the control index actually prove?
It shows where each finding touches a control you have committed to under Level 1 or Level 2. Note the limit, because it matters: those sixteen controls contain no testing requirement and most of them are organisational or architectural. So the index demonstrates coverage against the list, and it does not evidence the organisational controls themselves. A vendor presenting a control index as proof that you meet the controls is overselling it.
What does it cost?
Our published plans, because scope follows what you need to evidence rather than a requirement Shopify has written. The plan is the Compliance Plan at INR 1,79,999, which covers two scopes, and each further scope is INR 74,999. It is the Compliance Plan because the control index is per-finding control mapping, and that is a Compliance Plan deliverable. Most Shopify engagements are the app and its API. A suspended app usually needs more, because the assessment has to start where the incident did. Tell us which of the three moments you are in and we will scope against that, not against a template.
Does a custom app escape all of this?
It escapes app review, not the obligations. A custom app skips review entirely and Levels 1 and 2 are always available to it rather than requiring review. What does not change is the API License and Terms of Use: the 24 hour breach notification duty, the Internet industry standards obligation, Shopify’s audit rights and its right to suspend API access all apply exactly as they do to a public app. A custom app handling Level 2 data with no review in front of it carries the same risk with less scrutiny.
Tell us which moment you are in
Proving compliance on request, heading into a Level 2 data protection review, or sitting on a suspended app. Those three need different scopes and different deliverables, and the difference is worth getting right before you commit. Both co-founders are on the call.
Shopify names no required test, so scope follows the moment rather than a template. Published plan pricing is on the pricing page, and the report format is at our sample report.
Where these requirements come from
Everything this page says about the platform's requirements is taken from the platform's own published documentation, linked below and last checked on 2026-10-03. We quote the requirement rather than our reading of it wherever the difference matters.
- Shopify API License and Terms of Use
- Shopify: protected customer data requirements
- Shopify: app requirements checklist
Sections 7.1, 8 and 6.2.10 of the API Terms were re-read verbatim on 2026-10-03. The protected customer data control lists were last read on 2026-08-21.
Our aim is to describe these requirements as accurately and as currently as we can, and to show you where to check us. We are reading someone else's documentation: a platform can revise it without an announcement, and our reading of it can be imprecise or go out of date.
How we source, draft and review what we publish, including where software sits in the drafting, is set out in our editorial policy. A page like this is only as good as the date on it, so we re-read the sources on a standing audit, date what we checked, and update the page when a source moves or when we can state something more precisely.
If something here no longer matches the source, tell us at errors@cybersecify.com. We will review it against the source and tell you what we decide; where it needs changing we change it and date the change.
This page is published for information. It is a best-effort account of someone else's published requirements, not a commitment about your engagement: what we deliver, and what it costs, is set out in the Statement of Work both parties sign, and our terms state that where website content and a signed agreement differ, the signed agreement governs.