A Data Protection Policy rejection is a remediation request with a deadline attached, not a refusal. Amazon’s reviewers name specific controls. The work is to fix those controls, evidence each fix, and resubmit against the reviewer’s own wording, in the order Amazon’s own clocks dictate.
Read the rejection before you buy anything. The single most expensive mistake here is buying a penetration test for a rejection that was not about clause 2.7.2, and the second is answering a different question from the one the reviewer asked.
First, establish whether the DPP testing clause binds you at all
The testing clause is conditional, and most rejections are not about it. Clause 2.7.2 binds you only if you hold a restricted role, because it lives in the PII-conditioned half of the policy. Our SP-API DPP pentest pillar sets out why, with the clause text.
What matters here is the shorter version: check your declared roles first. Amazon marks five roles restricted: Direct-to-Consumer Shipping, Professional Services, Selling Partner Support, Tax Invoicing and Tax Remittance. If your application declares one of those, section 2 binds you. If it declares only non-restricted roles such as Pricing, Product Listing, Inventory and Order Tracking or Brand Analytics, a rejection is unlikely to be about clause 2.7.2 at all, and a penetration test will not answer what the reviewer asked.
The order is set by Amazon’s clocks, not by convenience
Clause 2.7.3 publishes the remediation windows: critical vulnerabilities resolved within 7 days of discovery, high-risk within 30 days.
🔴 Those clocks run from discovery, not from the rejection. So by the time a reviewer writes to you, part of the window may already be spent. That is why criticals and highs go first: not because they are the biggest risk in the abstract, but because they are the only items with a published deadline already running.
Amazon also states on its own listing-status page that applications found non-compliant in its periodic data security assessments “will be suppressed”. So the cost of a slow response is access, not just a delayed approval.
On the response deadline itself: Amazon does not publish a single global figure, and the date that matters is the one in the message you received. Work to that, not to anything on this page.
What a plan of action has to contain
There is no Amazon-published template, so the contents are driven by what the reviewer asked rather than by a form. The shape that survives review:
- The reviewer’s own control references as the headings. If they named three controls, those three are the structure. A general security summary answers a question nobody asked.
- One row per finding, with the severity, what was changed, the artefact that proves it, and a date.
- Anything not yet fixed, stated with its remediation date. An omission reads as either an oversight or an evasion, and both invite a second rejection.
- The clause 2.7.3 clocks kept visible, because they are Amazon’s own numbers and showing you are working to them is stronger than asserting that you take security seriously.
🔴 Two things make a resubmission fail twice. Answering a different question from the one asked. And evidencing a fix with the same artefact that was already rejected.
If testing was part of what the reviewer asked for
Then the retest is part of the work, not an optional extra. Amazon’s own vulnerability management guidance states that after remediation, solution providers must run a second penetration test to validate that all identified vulnerabilities have been completely remediated.
That is a policy obligation rather than a vendor upsell, and it is worth checking against any quote you receive: a test with no retest attached does not finish the job Amazon describes.
Both our plans include one free retest within one month of the v1.0 report, closing with a v2.0 report that supersedes it. We retest sooner when your fixes land sooner, which on a rejection clock is usually the point.
The half of a rejection a test cannot answer
Worth knowing before you scope, because it is where rejections get handled twice.
A penetration test evidences what is observable in a running system: access controls, application and API behaviour, external-facing components, system configurations, TLS, lockout behaviour, Key Management System usage, web application firewall configuration.
It does not evidence governance. Incident notification timelines, the 12-month log retention minimum, the designated Incident Management Point of Contact, documented data retention purposes, patch cadence, the geographically separated backup site with its RTO and RPO targets, and the annual third-party risk assessment of subcontractors clause 2.8 requires are policy and process obligations. A tester can observe that a control appears present. A tester cannot evidence that your organisation maintains it.
Our SP-API DPP evidence checklist splits the eight evidence areas by who produces each one: a penetration test produces one of the eight fully, three partly, and four are not testing problems at all.
Where we fit, and where nobody fits
Cybersecify performs the clause 2.7.2 penetration test and produces the report and the Letter of Engagement a submission takes. Our Amazon SP-API DPP penetration testing page maps the four scope categories to what we test, with the price and business days for a three and a four scope engagement.
🔴 What no vendor can do, including us. For restricted roles, Amazon’s documentation describes a two-phase path: business verification and a developer profile assessment, then a data security assessment focused on PII protection, plus an architecture review with Amazon’s own Solutions Architecture team. A testing vendor is not in that room and has no standing in that decision. There is no Amazon-issued DPP certificate, no approved assessor list, and no pass or fail letter for the pentest control. Amazon decides. Any vendor implying otherwise is describing a programme that does not exist.
Request the SP-API DPP evidence checklist. It splits the eight evidence areas by who produces each one: one is fully produced by a penetration test, three partly, and four are not testing problems at all. If you are holding a rejection, that split is the question you are actually trying to answer.
🔴 Send the reviewer’s exact wording with your request. We will tell you which of the eight areas they are asking about, and we will tell you plainly if a penetration test is not part of the answer. That costs you nothing and it is the cheapest way to avoid buying the wrong thing twice.
Corrections and updates
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 policy, 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.
Sources. Amazon Data Protection Policy clauses 2.7.2, 2.7.3 and 2.8, and sections 2 and 3, at sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US, read 17 October 2026. Restricted role list, five roles, at developer-docs.amazon/sp-api/docs/roles-in-the-selling-partner-api. The second-test-after-remediation requirement and the remediation windows at developer-docs.amazon/sp-api/docs/vulnerability-management. The two-phase review path at developer-docs.amazon/sp-api/docs/register-as-a-public-developer. The suppression statement at developer-docs.amazon/sp-api/docs/check-the-status-of-your-listing. Amazon publishes no response deadline for a rejection and no plan-of-action template; where this page describes what a plan should contain, that is our view of what answers a reviewer, not an Amazon requirement.