Amazon SP-API DPP Report Sample

One engagement, several scopes, one evidence set

Clause 2.7.2 of the Data Protection Policy requires penetration testing "at least every 365 days using an industry-recognized methodology" and enumerates four scope categories the testing must cover: network infrastructure, cloud environments, application-layer assets, and other in-scope systems as applicable. One scope does not reach four categories.

In practice that means a four scope engagement: the web application, the API backend, the cloud environment and the network. Each is tested as its own scope, because the effort, the test cases and the threat surface are genuinely different in each one. Where the estate allows, the work can come to three scopes instead of four, and that is a scoping judgement made on what is in front of us, settled before anything is quoted.

Do not count scopes by counting documents. The web application and its API backend are tested separately and reported together, because someone reading about one system should not have to hold two documents open to follow it. The number of reports describes how the findings read. It is never how the work was counted or priced.

These reports come from the same engagement, the same window and the same lead tester. That is the point of publishing them together: a reviewer receives a set, and the set is what has to hold up. What a three or four scope engagement costs is on pricing, and the obligation itself is explained in what the DPP actually requires.

Three documents, more scopes than documents. The web application and its API backend were tested as two separate scopes, because the effort, the test cases and the threat surface differ between them, and reported as one document because they share authentication and the same authorisation model. Counting the documents will undercount the work.

What clause 2.7 needs, and what we deliver

• The penetration test, which is the leg Amazon asks an independent firm to perform. The testing, the report, the free retest, and findings mapped to the numbered Data Protection Policy sections so a reviewer can follow them without translation.
• The paperwork a DPP submission actually takes. A Letter of Engagement evidencing that an independent firm was engaged, and a Letter of Attestation signed by the lead tester after the retest. Both are issued on the Growth plan.
• The compliance work around it. Per-finding mapping to SOC 2 Trust Services Criteria and ISO 27001:2022 Annex A where your auditor needs it, which is the same support we give a SOC 2 or ISO 27001 effort. Amazon itself asks for neither, so it is there for your auditors rather than for Amazon.
• The rest of 2.7, answered. Vulnerability scanning every 30 days, change-triggered scanning after significant changes, and per-release code scanning are three further obligations. We tell you what satisfies each one and what evidence to retain, so the submission goes in complete rather than one leg at a time.
• Independent evidence, reviewed by whoever has to accept it. Amazon reviews and decides the submission, and where a certificate is involved it is issued by an accredited auditor or a licensed CPA firm. Our job is to produce evidence that holds up in front of them, and the reports above are what that looks like.

One practical note: the policy makes the report a record you keep and produce on request, not something filed as a matter of course. Keep a dated copy.