Amazon’s Selling Partner API Data Protection Policy requires a penetration test at least every 365 days, but only for Solution Providers handling personally identifiable information. The clause sits in section 2.7, inside the section headed Additional Security Requirements Specific to Personally Identifiable Information. Section 1, which binds every Solution Provider, contains no penetration testing requirement at all. Amazon does not require an independent or third-party tester: its own guidance permits qualified security professionals or third-party firms. The pentest is also one of three legs in 2.7, alongside 30 day vulnerability scanning and code scanning before every release.
Everything below is quoted from Amazon’s own policy and developer documentation, and linked. Cybersecify does founder-led penetration testing for AI-first and API-first SaaS startups, and we wrote this because the small amount of published material on SP-API compliance repeats two claims Amazon’s documents do not support: that every integrator needs a pentest, and that it must be done by an external third party. Neither is true as stated.
Key findings
- The word “penetration” appears exactly once in the entire Amazon Data Protection Policy, inside section 2.7. We checked the full text of the live policy on 9 August 2026.
- Section 2.7 requires three separate things, not one: vulnerability scanning at least every 30 days, penetration tests at least every 365 days, and code scanning for vulnerabilities prior to each release.
- The requirement is PII-scoped. Section 2 opens by stating those requirements apply to PII, granted on a must-have basis for select tax and merchant fulfilled shipping purposes. Section 1, the general requirements, has no pentest clause.
- Amazon does not mandate a third-party tester. Its security controls guidance says to perform annual penetration testing “using qualified security professionals or third-party firms”.
- Remediation clocks are tight: critical risk impact vulnerabilities within 7 days, high-risk impact vulnerabilities within 30 days of discovery.
- A second test is expected after remediation. Amazon’s vulnerability management guide states that after the remediation stage, Solution Providers must run a second penetration test to validate that all identified vulnerabilities have been completely remediated.
What the policy actually says
Here is section 2.7 in full, because most write-ups paraphrase it into something stricter than it is:
“Solution Provider must create and maintain a plan and/or runbook to detect and remediate vulnerabilities. Solution Provider must protect physical hardware containing PII from technical vulnerabilities by performing vulnerability scans and remediating appropriately. Solution Provider must conduct vulnerability scanning at least every 30 days, penetration tests at least every 365 days, and scan code for vulnerabilities prior to each release. Critical risk impact vulnerabilities must be remediated within 7 days, and high-risk impact vulnerabilities must be remediated within 30 days of discovery.”
The clause continues with availability requirements: procedures and plans to restore availability and access to PII in a timely manner after a physical or technical incident, and a geographically separated secondary or backup site to support timely restoration against defined RTO and RPO targets.
One note on sourcing. The live DPP page carries no version number and no effective date. We searched the full fetched document for one. If you are building a compliance file, save a dated copy of the policy text you relied on, because you cannot cite a version.
The scoping catch nobody mentions
Section 2.7 does not sit in the general requirements. It sits inside section 2, which opens:
“The following additional Security Requirements must be met for Personally Identifiable Information (“PII”). PII is granted to Solution Provider for select tax and merchant fulfilled shipping purposes, on a must-have basis. If an Amazon Services API contains PII, or PII is combined with non-PII, then the entire data store must comply with the following requirements.”
Section 1, General Security Requirements, runs from 1.1 Network Protection through 1.8 Data Attribution and covers firewalls, access management, least privilege, credential management, encryption in transit, risk management and incident response, deletion and data attribution. There is no penetration testing clause in it.
Practically, the pentest obligation follows the restricted roles. Amazon’s roles documentation marks four roles as restricted, meaning they require sensitive information which might include PII:
| Restricted role | What it is used for |
|---|---|
| Direct-to-Consumer Shipping (Restricted) | Shipping orders directly to customers; order reports, order tracking reports, EasyShip |
| Professional Services (Restricted) | Add-on services such as assembly and installation, via the Services API |
| Tax Invoicing (Restricted) | Generating tax invoices to comply with tax regulation |
| Tax Remittance (Restricted) | Calculating and remitting sales taxes |
Non-restricted roles include Pricing, Product Listing, Inventory and Order Tracking, Finance and Accounting, Brand Analytics, Buyer Communication, Amazon Fulfillment and others. Amazon’s own description of Inventory and Order Tracking is explicit that operations requiring it do not use the PII required to ship an order.
Check your roles before you buy anything. If you hold no restricted roles, section 2 is not the section that binds you. A pentest may still be a good idea, and an enterprise seller or an investor may ask for one, but that is a different reason with a different scope conversation.
Who is allowed to perform the test
This is where the published material is most consistently wrong. Amazon’s security controls guidance says:
“Perform annual penetration testing using qualified security professionals or third-party firms and scan application code prior to each software release.”
Qualified security professionals or third-party firms. In-house testing is permitted, provided the people are qualified. Amazon names no accreditation body, no approved vendor panel and no required certification anywhere in the DPP, the vulnerability management guide or the security controls guidance.
The only independence language in the policy is in section 3, and it points the other way. It concerns Amazon’s right to audit you, either itself or through “an independent certified public accounting firm selected by Amazon”. That is Amazon’s auditor, not yours.
This is not unusual, and it is worth knowing the pattern. The PCI Security Standards Council takes the same position in its own Penetration Testing Guidance information supplement (version 1.1, September 2017), which states that “qualified internal resources or a qualified third party may perform the penetration test as long as they are organizationally independent”, and lists tester certifications as an indication of skill while noting they are not required certifications. Programmes that genuinely lock testing to an accredited panel say so in plain language. When the wording is open, it is open.
If a vendor tells you Amazon requires an external third party, ask them to point at the line. There isn’t one.
Scope: what to test
The policy’s applicability statement is the outer boundary:
“This policy is applicable to all systems that store, process, or otherwise handle data vended and retrieved from the Amazon Services API.”
In practice, for a typical SP-API integrator, that reads as:
| Surface | Why it is in scope |
|---|---|
| The integrating web application | Authentication, session handling, authorisation between seller accounts, and anywhere Amazon data surfaces to a user |
| Your API and backend | The code that calls SP-API, handles tokens, and moves Amazon data between services |
| Datastores holding Amazon data | Section 2 states that if PII is combined with non-PII, the entire data store must comply |
| Hosting environment | Amazon’s guidance directs you to test both external-facing infrastructure and internal systems |
| Connected environments | Anything that stores, processes or handles data retrieved from the API |
Amazon publishes no per-surface checklist and mandates no methodology, so the scope is yours to define and to defend if audited. Two practical notes from Amazon’s own pages. It tells you to review its AWS penetration testing guidance before testing AWS services, which matters if you are hosted there. And its security controls guidance explicitly names internal systems alongside external-facing infrastructure, so an external-only scope is a narrower reading than Amazon’s wording invites.
One thing to keep out of your scope document. Claims that Amazon specifically expects OAuth 2.0 or Login with Amazon token lifecycle coverage, or a particular grey-box framing, come from vendor marketing rather than Amazon documentation. Token handling is worth testing on its merits, and our API security testing guide covers it against the OWASP API Security Top 10 2023. Just do not write it into a compliance document as an Amazon requirement.
If you are unsure whether your engagement should be an API test, a web application test, or both, API pentest vs web app pentest walks through the difference.
Evidence: what Amazon actually asks you to hold
There is no routine report submission. What section 3 requires is:
- Records. All appropriate books and records reasonably required to verify compliance with the Acceptable Use Policy, the DPP and the Developer Agreement, kept during the agreement and for 12 months after.
- Written certification on request. Upon Amazon’s written request, you must certify in writing that you are in compliance with these policies.
- Cooperation with audit. Amazon may, on reasonable request, audit, assess and inspect the books, records, facilities, operations and security of all systems involved in retrieving, storing or processing Amazon data, either itself or through an independent certified public accounting firm it selects. The audit may occur at your facilities or a subcontractor’s.
- Remediation at your cost. If deficiencies are found you must remediate at your sole cost within an agreed timeframe, provide remediation evidence in the form Amazon requests, and obtain written approval before closure.
Separately, registering as a public developer for restricted roles puts you through a two phase review: Phase 1 business verification and developer profile assessment, Phase 2 a data security assessment covering data flow architecture, PII protection controls, storage and handling procedures, security protocols, and incident response and breach procedures. Amazon also says restricted role applicants should prepare for an architecture review with the SP-API Solutions Architecture team, which can involve a screen sharing demo. Amazon’s documentation does not name a penetration test report as a required artefact of that review.
What this means for your report. Nobody at Amazon is grading the formatting, but you need a document that survives being handed to an auditor a year later: dated, scoped explicitly, findings with reproduction steps, severity aligned to the 7 day and 30 day remediation clocks, and retest evidence attached. Our sample report shows the structure we ship, and how to read a VAPT report covers what to look for in anyone’s.
The annual cycle Amazon describes
Amazon’s vulnerability management guide sets out penetration testing in five stages: planning, scan and discovery, penetration, analysis and report, and remediation and clean up. Then it adds the line that turns it into a cycle:
“After the remediation stage, solutions providers must run a second pen test to validate that all identified vulnerabilities have been completely remediated.”
Combined with section 2.7’s remediation clocks, the calendar looks like this:
| Step | Timing driver |
|---|---|
| Penetration test | At least every 365 days |
| Remediate critical risk findings | Within 7 days of discovery |
| Remediate high-risk findings | Within 30 days of discovery |
| Second test to validate remediation | After remediation |
| Vulnerability scanning | Every 30 days, continuously |
| Code vulnerability scanning | Before every release |
Planning consequence: do not book the test for the week before a major release. The 7 day critical window and the retest both have to land somewhere, and a release in the middle of that changes what the retest is even testing.
Amazon ships a free tool for part of this
Worth knowing before you spend anything. Amazon describes SP-API Guard as:
“a serverless application that scans Amazon Web Services (AWS) accounts to assess security compliance with Amazon’s Data Protection Policy. It leverages custom scan rules built with AWS Security services to look for security gaps, and then returns a findings report with clear remediation recommendations after 24 hours.”
It is free and it takes very little to set up. Run it first. It covers configuration assessment of your AWS account against DPP requirements, which is real work you would otherwise pay someone to do.
Guard looks inward, at the AWS account. For the outward view, a free external attack surface scan maps what your integration exposes to the internet: live subdomains, open ports, TLS and certificate state, and known CVEs on the services it reaches. Neither one is the annual penetration test.
What it does not do is satisfy the penetration test control. Guard assesses configuration; it does not manually test authentication, authorisation between seller accounts, or business logic in your application. Amazon’s own guide lists Guard and Amazon Inspector under tooling and describes penetration testing separately as a five stage exercise with a human tester attempting exploitation. The distinction is the same one we cover in manual pentest vs automated scanning.
Who this applies to
Solution Providers building on the Selling Partner API who hold restricted roles are the group section 2.7 binds. In our experience that skews toward AI-first and API-first SaaS startups building shipping, tax, invoicing or fulfilment tooling for Amazon sellers, where PII access is unavoidable because the product needs an address or a tax identity to work. If you are building pricing, listing or analytics tooling and hold no restricted roles, read the policy again before you assume the clause applies to you.
Where we fit, and where we don’t
Section 2.7 has three legs. We serve one of them well, and we would rather say so than let you find out after signing.
The pentest leg: yes. Cybersecify does founder-led manual penetration testing of web applications, APIs and cloud environments, with both founders on every engagement. A two scope engagement covering the integrating application and its API backend maps cleanly onto a typical SP-API integration. Our Growth Pentest is INR 1,79,999 for two scopes over 10 business days, and includes one full retest within one month of the v1.0 report, closing with a v2.0 report that supersedes v1.0 with updated status per finding and fresh proof for each fix. That retest is the second test Amazon’s guidance asks for. A single-surface integrator fits the Startup Pentest at INR 74,999.
Internal systems testing, which Amazon’s guidance names alongside external-facing infrastructure, is also within what we do. Whether it belongs in your engagement depends on how much of your estate you manage yourself, so it is settled during scoping. Start at contact with your architecture rather than at a plan.
The 30 day vulnerability scanning leg: not from us. We do not sell recurring monthly scanning as a service. Look at your cloud provider’s native tooling first, since Amazon’s own guide points at Amazon Inspector for workload and network exposure scanning and at SP-API Guard for DPP-aligned configuration assessment. If your estate is broader than AWS, the market for recurring external scanning is well served and inexpensive. What you should insist on is that whatever you buy produces dated, retained output, because section 3 is a records requirement.
The per-release code scanning leg: not from us. We do not sell SAST, DAST or IAST tooling or CI pipeline integration. Amazon’s guide names all three classes and expects the scan to run before every release, which makes this a build-pipeline problem rather than an engagement. Your existing CI platform very likely has a scanning step already. Turn it on, gate the release on it, and keep the output.
What nobody can sell you. There is no Amazon-issued certificate for DPP compliance, no approved assessor list to be on, and no pass or fail letter for the pentest control. Any vendor implying otherwise is describing a programme that does not exist. What exists is a records obligation and an audit right, and your job is to be able to answer it.
If you want to sanity check what a manual engagement should cost and include before talking to anyone, pentest cost in India lays out the bands and the seven questions worth asking any vendor.
Corrections
- 2026-08-09: Added a direct link to our internal network pentest service page, which Amazon’s guidance names alongside external-facing infrastructure. The page previously routed readers to the contact form without naming the service.