If your Shopify app was delisted and you were told nothing, the first decision is not which firm to hire, it is whether you need one at all. Shopify publishes several causes for removal that need no security work, and it publishes none of its reinstatement criteria, so the notice you were sent is the only document that tells you which situation you are in. What follows is how to read it, what Shopify actually publishes about an incident, what a Partner Governance enforcement notice asks for in practice, and which part of that stops most vendors.
The reason this decision is hard is that the platform does not help you make it. Shopify publishes an appeal route for an app removal, and the only trigger it states for that route is believing a mistake has been made. There is no published reinstatement standard, no stated criteria and no timeline. The same page states that Shopify “can’t share specific information about an investigation unless required by law”, so the general case is undocumented by design rather than by oversight.
Third-party trackers appeared during the October 2026 delisting wave to list removed apps. They were written for merchants who had installed a delisted app, not for the developer whose app came off the store. They publish no methodology, they disagree with each other on both the number removed and the number recovered, and they change daily. Nothing on this page rests on them.
So the developer is left with a listing that is gone, a notice that may or may not describe a security problem, and a quote in their inbox.
Which situation are you in
Shopify publishes five families of reason for removing an app, and four of them need no security work at all. Only the fifth, a security incident, is the family where the contract names investigation and remediation and bills them to you. The full list of published reasons an app is removed sets out each family and the route back for it, and reading that first is the cheapest move available to you.
The notice is the discriminator, not the outcome of somebody else’s case. Two notices look very different from each other. One asks you to confirm a listing fact, update an unsupported API version, or fix a policy problem, and says nothing about malicious content, tokens or merchant data. The other describes content being served from your app that should not have been, tells you to rotate your API secret key, and asks which shops may have been affected. The first is not an incident. The second is.
Three practical readings follow.
If your notice says nothing about a security problem, do not retrofit one. Reply on the thread it came in on, confirm what it asked you to confirm, and fix the thing it names. An incident report written for an incident that was never alleged does not help a reviewer and does not shorten anything.
If your notice describes malicious content being served from your app, the work is genuinely required, and the realistic shape of it is weeks rather than days. Not because a platform publishes a duration, but because of what the work is: establishing root cause from the code and from controlled testing, establishing who was affected from records that either exist or already do not, remediating, and then having the result independently tested and retested. The sooner the independent test starts, the sooner that clock starts.
And check which restoration you are actually waiting on, because there are two. A theme app extension being switched off and switched back on is a different mechanism from an App Store listing being delisted and relisted. The two can move independently, and public discussion conflates them constantly. A vendor who reads somebody else’s fast extension recovery as a listing recovery will badly misjudge their own timeline. Check your own app’s status in your Partner Dashboard rather than inferring it from a list.
What Shopify publishes, and what a notice asks for
Keep these two apart. Almost everything written about Shopify reinstatement runs them together, and that is where providers and vendors both lose the first week.
What Shopify publishes is contractual, and it is short. Section 6.2.10 of the API License and Terms of Use requires notification of any actual or suspected breach or compromise of Merchant Data “no later than twenty-four (24) hours” of becoming aware, and then requires you, “at your own cost”, to promptly remedy the breach, investigate the incident, take reasonable actions to mitigate it, and promptly answer Shopify’s questions. Section 7.2 requires your systems to be configured to Internet industry standards. Section 8 requires proof of compliance on request. Section 13.1 leaves the decision over your API access with Shopify.
🔴 Shopify mandates no penetration test. Not to list, not to relist. There is no published incident report template, no reinstatement control list, no evidence format and no deadline. Worth stating plainly because it is commonly misreported, including by firms selling the test. Our reinstatement evidence page and our Partner Governance requirements guide say the same thing from the listing side, and that page records the search: 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 Terms mention no penetration test, no vulnerability testing and no third-party security assessment.
Testing is still usually the most legible way to produce the proof Section 8 asks for. A reviewer outside your company can read reproducible findings with evidence attached, and a claim that an app is now clean reads differently when somebody independent of the build team wrote it. That is a means, not a mandate, and the distinction decides what you should be buying and why.
What a Partner Governance enforcement notice asks for is a separate thing, and it is not published policy. It is a private email to one vendor. In reinstatement work we have delivered, what the notice asks for has had this shape.
An incident report containing four elements:
- Root cause of the security incident, with supporting evidence
- Scope of impact
- Timeline of the incident
- Detailed mitigation and remediation steps taken
A vulnerability assessment and penetration test from a third-party security provider. The ask is specific about what that test has to do: confirm that no other security vulnerabilities exist in the app, include evidence of each vulnerability and how it was tested, show what controls were added when the issues were fixed, and provide re-testing results.
And a timeline, both for when the two documents will arrive and for when the findings in them will be addressed.
Alongside those, the notice asks you to confirm you have identified the source of the malicious content, to review API token access logs for anomalies, to remove the content treating it as a high severity issue, and to rotate and remove the app’s API secret key immediately. Where personal data may have been involved, it asks for a description of what was exposed and a list of every impacted shop, by Shop ID or myshopify URL.
🔴 We cannot tell you that your notice says this, and we will not pretend otherwise. Shopify does not publish the template, so nobody outside the company knows how much it varies by case or how often it changes. Treat the list above as what to expect, not as what you were asked, and work from the document in front of you. Where anything in it is ambiguous, ask in writing exactly what evidence is wanted. Reply on the thread the notice arrived on: Shopify states that the address these notices come from “isn’t actively monitored” and that “Shopify Support is unable to provide updates on these tickets”, so a support ticket is the slower route, not the safer one.
That last item on the list, the impacted shops, is the one worth planning for, and it is the subject of the next section.
The element that stops most vendors
Of the four incident report elements, three are usually achievable. Root cause and remediation can be established from the code and from controlled testing. Timeline can usually be reconstructed.
Scope of impact is the one that stops people. Answering “which shops were affected, by ID” requires evidence about what your application was doing on dates that have already passed. Most app vendors do not have that evidence, because the logging that would prove it either did not exist, did not retain far enough back, or did not record the thing that turned out to matter.
This is not a criticism of anyone’s engineering. Nobody instruments an application for an incident they have not had yet, and retention is a cost decision that looks correct right up until the week it does not.
But it has three consequences worth knowing before you commission anything.
First, it decides whether an incident report can fully meet the ask at all. If the question cannot be answered from evidence, the honest report says what was searched, what was found and what could not be determined. That is a legitimate report. It is not the same document as one that answers the question outright, and you should know which one you are buying.
Second, it is the part that takes the time. Root cause is often a day’s work. Establishing scope against an incomplete record is where the weeks go.
Third, it is worth asking a prospective provider about directly. Ask how they establish scope of impact when application logs are not available for the period in question. A provider who has done this work will describe what they would look for and will also tell you plainly when the answer will be partial. A provider who says it is straightforward has either not done it or is not telling you something.
Why your normal triage instinct is wrong here
A reinstatement review is not a risk assessment.
The reviewer is not deciding which of your findings were serious enough to matter. They are checking that the report you submitted has been closed out, and where a notice asks for a test, that test’s stated job is to confirm no other security vulnerabilities exist.
That makes the standard engineering instinct the wrong model for this one situation. On a roadmap, criticals go this sprint and lows get a ticket for next quarter, and that is correct prioritisation. For a relisting it is not, because a low left open is still an open item in the document under review.
Three things follow:
- Budget the remediation for everything in the report, not just the top of it.
- Budget the retest for everything too. A retest that closes half the findings produces a document that reads partially resolved, and a partially resolved document does not start the review, it delays it.
- Do not submit until it is closed. The submission is not a progress update.
Shopify publishes no triage rule for any of this. The three points above are our judgement about what reads as closed to a reader outside your company, not a requirement we are reporting.
What you control, and what you do not
You control the documents, the remediation and the speed. That is more than it feels like at the point the listing disappears.
You do not control the decision. Shopify decides reinstatement, publishes no criteria for it, reserves its discretion over your API access in Section 13.1, and no vendor can commit to that outcome. Treat a promise of reinstatement as a reason to walk away, because it is a promise about somebody else’s decision.
One more thing that is yours rather than your assessor’s. Once the documents are accepted, the remaining clock belongs to your engineering team, because what follows acceptance is remediation and a retest. Knowing that in advance is the difference between a plan and a wait.
If the notice is in front of you now, the order is: read what it actually asks for, work out which of the two situations you are in, establish whether scope of impact is answerable from evidence you still have, and only then decide what to commission. The full list of published reasons an app is removed is worth reading first, because four of the five families of reason need no security work at all. If you have established that you do need the documents, what the evidence has to carry and the email to send first covers the submission itself, and the Partner Governance security requirements covers what listing requires in the first place.
Cybersecify is a founder-led penetration testing firm in Bengaluru, India, working with AI-first and API-first SaaS startups. We deliver the incident report and the independent penetration test that a Shopify Partner reinstatement submission usually rests on, and the Shopify Partner Governance security work behind it. Shopify alone decides reinstatement, and we do not commit to that outcome.
Corrections and updates (1)
We publish corrections rather than editing them away, so a reader who acted on an earlier version can see what changed. Some entries record a change in the source document itself, others record our own error. Dates are our review dates, not the source's change date.
Errors in this page are corrected in place with a dated note. If you believe something here misreads the programme, tell us at errors@cybersecify.com and we will check it against the source and publish the outcome either way. Our corrections policy sets out how.
- 2026-11-02: 🔴 This page said Shopify requires a penetration test to relist a delisted app. It does not, and the page contradicted five of our own surfaces, including the reinstatement evidence page, which states correctly that Shopify mandates no penetration test to list or to relist. A sweep of Shopify’s published corpus, the app documentation, the Partner Program Agreement, the API License and Terms of Use and the partner enforcement help page, finds no occurrence of penetration testing, a security assessment or a security audit as a requirement on an app developer. The requirement text this page quoted comes from a private Partner Governance enforcement notice, and the page presented it under the heading “what the platform actually requires”. It also asserted that “the same structure goes to every vendor in that position” while declaring the claim was “not inferred”. Nobody outside Shopify can know that, because the template is not published. The page now states what Shopify publishes and what a notice asks for as two separate things, and keeps the point that testing is often the most legible way to produce the proof, which is a means rather than a mandate. Separately, the recovery rate and recovery timing figures have been removed outright. They came from third-party delisting trackers that this page itself described as publishing no methodology, disagreeing with each other and changing daily, and the spread between the recovery rates was far too wide for any caveat to rescue. The page’s argument never depended on them. A sources section, which this page should have carried from the start and was the only one of our four Shopify posts without one, has been added.
Sources
Every Shopify document below was read on 2026-11-02.
- Shopify API License and Terms of Use. Section 6.2.10 for the 24 hour breach notification and the at-your-own-cost duty to remedy, investigate, mitigate and answer questions; Section 7.2 for Internet industry standards; Section 8 for proof of compliance on request; Section 13.1 for Shopify’s discretion over API access
- Enforcement of Shopify’s Partner Program Policies. The appeal route and its only stated trigger, the investigation confidentiality line, the unmonitored notice address, and the instruction to reply to the notice rather than open a support ticket. This page carries no revision date of its own, which is worth knowing for a document this consequential
- Shopify Partner Program Agreement. The identically worded breach notification duty, and termination without notice to or recourse for the Partner
- Work with protected customer data. Level 1 and Level 2 requirements and data protection reviews, checked for any testing requirement
- App Store requirements checklist. Checked for any testing requirement
- About the app review process. Checked for any testing requirement
- About app security and App security checks. Shopify’s own static check and the limits Shopify publishes for it
🔴 No figure or count on this page comes from a third-party delisting tracker. Where this page describes what a Partner Governance enforcement notice asks for, that comes from reinstatement work we have delivered rather than from a Shopify document, and Shopify publishes no such template. Where it describes what a reinstatement submission should contain, that is our view of what answers a reviewer, not a Shopify requirement.