Amazon SP-API DPP Evidence Checklist

What Amazon asks a solution provider to produce under the Selling Partner API Data Protection Policy and its Solution Provider Security Assessment, across eight areas, with the clauses each one maps to.

Current to the policy revision effective 25 August 2026. Clause numbers verified against Amazon's published policy text on 15 October 2026.

One of these eight is produced by a penetration test

That is the number worth knowing before you budget for a submission. Clause 2.7.2 requires a penetration test at least every 365 days, which in practice means once every year, and it is the clause most vendors lead with. It sits inside one of the eight areas below.

Three more are partly evidenced by testing. A test can demonstrate that TLS configuration, edge and WAF behaviour, account lockout, MFA enforcement and secrets exposed in client-side code are working as described. The policies and records behind those controls stay yours to hold. The remaining four are not testing problems at all.

So a buyer who reads "annual penetration test required", books one and stops has covered one area of eight. The gap does not appear until a reviewer asks for the other seven, by which point the clause 2.7.3 remediation clocks are already running.

What Amazon asks you to produce

Grouped by what you hand over rather than by clause number, which is how a submission actually puts the question to you.

Area What Amazon asks for DPP clauses Pentest
1. Network and infrastructure security Architecture diagram, internet-facing endpoint list, edge and WAF protections, detection, configuration monitoring. 1.1.1, 1.1.3, 2.3.1, 2.6.2 Partly
2. Endpoint and device security Malware protection, disk encryption, device restrictions, personal device policy. 1.1.2 No
3. Access control and authentication Unique accounts, access reviews, MFA, password policy, API key handling. 1.2.1 to 1.2.4, 1.4.1, 1.4.2 Partly
4. Data protection, encryption and privacy Data attribution, encryption in transit and at rest, DLP, retention and deletion. 1.4.2, 1.2.3 Partly
5. Development and vulnerability management Secure SDLC, scan reports, the remediation clocks, and the annual penetration test. 2.7.1, 2.7.2, 2.7.3 Yes
6. Monitoring, logging and incident response Centralised logging, alert review, exposure monitoring, incident response plan, named Incident Management Point of Contact. 2.6.1, 2.6.2, 1.6.2 to 1.6.5 No
7. Operational and governance controls Backups and restore tests, asset and change management, training, the policy set. 2.7.4, 2.3.1, 2.3.2, 1.6.1 No
8. SP-API specific obligations Data usage limits, transparency, prohibited activities, affiliates, notifications. Section 3 No

"Partly" means a penetration test evidences some items in that area while the policies and records behind them remain yours to hold. Clause numbers follow the live policy text; the full derivation, including where encryption does not map to a single clause, is published in our clause map.

Every item, what satisfies it, and who produces it

The table above is the shape. The checklist itself goes item by item inside each of the eight areas: what specifically satisfies each one, whether you produce it or an engagement does, and how Amazon weights it. It is the document we work from on a DPP engagement.

We send it on request rather than publishing it, and a founder reads the request first. Tell us what you run and you will get a view on scope with it.

Ask for the full checklist

SP-API DPP evidence questions

What evidence does the Amazon SP-API Data Protection Policy require?

Amazon asks a solution provider to produce evidence across eight areas: network and infrastructure security, endpoint and device security, access control and authentication, data protection and encryption, development and vulnerability management, monitoring and incident response, operational and governance controls, and the SP-API specific obligations. The penetration test sits inside the fifth of those, under clauses 2.7.1 to 2.7.3. Amazon runs the review as the Solution Provider Security Assessment, which sits alongside the Data Protection Policy rather than inside it. Source: the Data Protection Policy on sellercentral.amazon.com, read 15 October 2026.

Does a penetration test cover the whole SP-API DPP submission?

No, and this is the most expensive misunderstanding in the process. Of the eight evidence areas, a penetration test produces one: development and vulnerability management, which is where clause 2.7.2 lives. Three more are partly evidenced by testing, because a test can demonstrate TLS configuration, edge and WAF behaviour, account lockout, MFA enforcement and secrets exposed in client-side code are working as described. The policies and records behind those controls remain yours to hold. The remaining four areas, endpoint and device security, monitoring and incident response, operational and governance controls, and the SP-API specific obligations, are not testing problems at all. A buyer who reads "annual penetration test required", books one and stops has covered one area of eight.

What is the Solution Provider Security Assessment?

It is the review Amazon runs when a solution provider applies for restricted roles, the roles that give access to personally identifiable information. It sits alongside the Data Protection Policy rather than inside it, and it is where most of the evidence that is not a penetration test ends up. Amazon describes a two phase path for restricted roles: business verification and developer profile assessment, then a data security assessment focused on how personally identifiable information is protected, plus an architecture review covering data flows and protection controls. A testing vendor is not in that room and has no standing in the decision.

Did the Data Protection Policy change recently?

Yes. A revision took effect on 25 August 2026. Amazon states it added a web application firewall requirement for internet-facing endpoints, storage encryption on all devices, a 15 minute screen lock, a 30 minute lockout after ten failed login attempts, a designated Incident Management Point of Contact, credentials encrypted at rest, deletion within 30 days where required, and expanded vulnerability scanning and penetration testing requirements including, in Amazon's words, for Application Programming Interfaces. Worth knowing if you track policy changes through Amazon's SP-API changelog: its most recent entry is still 25 November 2025, so the August 2026 revision appears only on Amazon's separate announcement page. Source: developer.amazonservices.com policy update announcement, read 15 October 2026.

Do I have to submit the penetration test report to Amazon?

Not routinely. Section 3 of the Data Protection Policy makes the report a record you keep and produce on request, together with written certification of compliance when Amazon asks for it, rather than a document filed as a matter of course. Keep a dated copy. The practical consequence is that the report has to survive being read a year later by someone who was not in your standups, which is a higher bar than passing a review on the day.

Get the checklist as a PDF by email

The page above sets out the eight areas and the clauses each maps to. The checklist document itself goes item by item, with who produces each one and which items a penetration test evidences for you. We send it on request rather than publishing it, and a founder reads the request first.

A founder reads the request and sends what you asked for. We keep your details only to follow up on whether a DPP engagement fits your stack. No spam, no third-party sharing.

The rest of the SP-API material