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, under Additional Security Requirements Specific to Personally Identifiable Information. Section 1, which binds every Solution Provider, has no penetration testing requirement at all. Clause 2.7.2 enumerates four scope categories: network infrastructure, cloud environments, application-layer assets, and other in-scope systems. The pentest is one of three legs in 2.7, alongside 30 day vulnerability scanning and code scanning before every release. Amazon does not ask you to submit the report; section 3 makes it a record you keep.
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.
If you already know the clause binds you and you are now choosing a tester, the companion piece covers what a qualifying test looks like and how to evaluate a vendor: SP-API DPP pentest, why scanner output fails.
Key findings
- The word “penetration” appears five times in the Amazon Data Protection Policy, all inside clause 2.7 (the 2.7.2 heading, three sentences within it, and once in 2.7.3). It appeared exactly once before Amazon restructured 2.7; that is no longer true and the earlier claim is corrected here rather than removed. We reviewed the full text of the live policy on 9 August 2026, again on 22 August 2026, and again on 29 August 2026. Amazon’s restructuring of 2.7 took effect on 25 November 2025, so it predates all three of those reviews. Our 9 August review did not catch it, which is why the earlier version of this page described the pre-restructure text. The dates marked “UPDATED” below are OUR review dates, not Amazon’s change dates. Corrections are marked inline rather than quietly edited away, because a reader who acted on the earlier version deserves to see what changed.
- 🔴 CORRECTED ON OUR SIDE 22 August 2026 (Amazon’s change took effect 25 November 2025): 2.7 is four numbered subsections, 2.7.1 Vulnerability Scanning, 2.7.2 Penetration Testing, 2.7.3 Vulnerability Remediation and 2.7.4 Disaster Recovery and Business Continuity, and 2.7.2 now requires an ‘industry-recognized methodology’ plus four enumerated scope categories. If you are working from a copy saved before that, re-read it.
- 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, and the permission carries a condition. Its security controls guidance says to perform annual penetration testing “using qualified security professionals or third-party firms”. The equivalent PCI wording, which is the standard most teams reach for next, permits internal testers only “as long as they are organizationally independent”. A team testing the product it built usually is not. What you actually give up by keeping it in-house is set out below, so you can price the choice rather than assume it.
- 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 on the policy page itself. The date does exist, just not where you would look for it. Amazon’s SP-API changelog records the current revision as effective 25 November 2025, and lists what changed: Developer became Solution Provider, account lockout after 10 failed logins, 10-password history, regular API key rotation, TLS 1.2+ with KMS, a named Incident Management Point of Contact, non-PII retention capped at 18 months, log retention raised to 12 months, critical remediation in 7 days and high in 30, geographically dispersed backups, audit cooperation extended to Amazon’s affiliates and contractors, and mandatory third-party risk assessments for vendors and subcontractors. Save a dated copy of the policy anyway, because the policy page still will not tell you which revision you are reading. 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.
Read the PCI sentence in full before you decide to test in-house, though, because the permission carries a condition. Qualified internal resources may perform the test “as long as they are organizationally independent”. A team testing the product it built usually is not, and that is the half vendors quoting this in your favour tend to leave out. Three things you give up by keeping it in-house, so you can price the choice rather than assume it. The Letter of Engagement, which is the document you hand Amazon, is issued by the firm running the test; an internal team cannot issue itself one. Organisational independence, per the sentence above, is the condition PCI attaches and the one Amazon’s own audit right in section 3 assumes. And if Amazon rejects the submission, a firm re-tests and re-issues under the original engagement, whereas an internal team absorbs the delay while the integration stays blocked. None of that makes an in-house test non-compliant. It makes it a trade you should make deliberately.
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.
The rest of the policy, and why this page covers one clause
Clause 2.7.2 is the clause that names a penetration test, which is why a pentest vendor has anything to say about it. It is not the policy. The Data Protection Policy runs to four sections and 17 numbered clauses, most carrying sub-clauses of their own, and 2.7.2 is one line inside one of them.
Two things follow. Section 1 binds every Solution Provider handling Amazon information, while Section 2 adds obligations that attach specifically to personally identifiable information. So the part of the policy that binds you is almost always wider than the part a penetration test can evidence, and a vendor who only ever discusses 2.7.2 has shown you a keyhole view of your own obligation.
Here is the whole shape, with an honest answer on who does each piece. Quotes are from the policy text, verified 30 August 2026.
| Clause | What it requires | Who does this |
|---|---|---|
| 1.1 Network and application security | Firewalls, network ACLs, endpoint protection, architecture documentation | Pentest for the external surface. Your team implements. Endpoint and device controls are neither |
| 1.2 Access management | A documented request, approval, review and revoke process. Lockout “after no more than ten (10) consecutive unsuccessful login attempts”. Access removed “within twenty-four (24) hours of termination or role change” | Pentest for lockout and access controls as built. Audit prep for the process and the records |
| 1.3 Least privilege | Access “limited to minimum necessary” | Pentest. This is authorisation testing, cross-tenant isolation and IDOR work |
| 1.4 Credential management | MFA on all user accounts, passwords at a “minimum of twelve (12) characters”, and programmatic credentials “encrypted at rest, rotated at least once every twelve (12) months” | Pentest for MFA, credential handling and token rotation as implemented. Records prove the rotation actually happened |
| 1.5 Encryption in transit | ”TLS 1.2 or higher, SFTP, and SSH-2” | Pentest. One of the most direct clauses in the policy to evidence |
| 1.6 Risk management and incident response | Risk process reviewed by senior management annually, an incident response plan, notification to Amazon “within twenty four (24) hours”, evidence handling, a named incident contact | Audit prep. None of it is a testing problem |
| 1.7 Data deletion | Secure deletion “within 30 days” of Amazon’s notice | Audit prep, plus your engineering team |
| 1.8 Data attribution | A separate database, or a mechanism tagging the origin of data | Audit prep, checked in configuration |
| 2.1 Data retention | PII retained “no longer than 30 days after order delivery” | Audit prep |
| 2.2 Data governance | A documented privacy and data handling policy | Audit prep |
| 2.3 Asset management | ”baseline standard configurations”, patching, and a change management process | Audit prep, with configuration observed during a test |
| 2.4 Encryption at rest | ”at least AES-128 or RSA with 2048-bit key size or higher” | Partly a pentest observation, mostly configuration review |
| 2.5 Secure coding | ”must not hardcode sensitive credentials in code”, test and production separated | Partly pentest, mostly your engineering practice |
| 2.6 Logging and monitoring | Logs gathered for security events, held for a minimum period, and monitored so suspicious activity raises an alarm | Pentest can show whether PII is reaching your logs. Retention and alerting are records and configuration |
| 2.7 Vulnerability management | Scanning every 30 days, penetration testing “at least every 365 days”, 7 day and 30 day remediation clocks, disaster recovery | 2.7.2 is the engagement. The rest is recurring process |
| 2.8 Subcontractors | Third-party risk assessment “on an annual basis” before granting access | Audit prep |
| 3 Audit and assessment | Records kept for 12 months, written certification on request, cooperation with an Amazon audit | Audit prep. This section is why the records matter at all |
Count the right-hand column and the split is stark. A penetration test speaks directly to roughly five clauses and partially to a handful more. Most of the policy is governance: process you can describe, records you can produce, and decisions someone has to have made and written down.
That governance half is real work and somebody has to do it. It is what our security audit and compliance readiness line exists for, and it covers most of the right-hand column above: access lifecycle and identity review, encryption and key management, incident response plan evaluation, logging and monitoring, data classification and handling, vendor and third-party risk, change management, and the evidence collection that Section 3 turns into an obligation. If you are buying the pentest from us and staffing the rest yourself, that is a perfectly good answer. We would rather you made that choice knowing the shape of what is left.
Why this list will need re-checking. Amazon revises this policy without announcing it, and quietly. Our own corrections log below records five claims on this page that decayed when clause 2.7 was restructured, effective 25 November 2025, nine months before we first reviewed it. Treat any clause table, ours included, as accurate on its stated date and not after. We re-verify this one quarterly.
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 is also within what we do, and it is named in the policy itself rather than in the advisory guidance: clause 2.7.2’s first scope category is “network infrastructure, including public-facing and internal network boundaries, firewalls, routers, and switches”. 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-30: Corrected an attribution. This page said internal systems testing is something “Amazon’s guidance names alongside external-facing infrastructure”. It is named in the Data Protection Policy itself, clause 2.7.2, not in the advisory security-controls guidance, and Amazon’s wording in that clause is “public-facing and internal network boundaries”. The policy binds; the guidance advises, so the earlier wording understated the requirement.
- 2026-08-30: Rewrote the pricing answer. It presented the Startup plan as suiting “a single-surface integrator” and cited SOC 2 and ISO 27001 control mapping as what makes the Growth plan fit. Both were misleading for this buyer. Clause 2.7.2 enumerates four scope categories that one scope cannot reach, and the Letter of Engagement, which is the document Amazon receives, is issued on the Growth plan only. The DPP contains no SOC 2 or ISO 27001 requirement at all, so control mapping is useful to your auditors rather than to Amazon.
- 2026-08-30: Corrected the date attribution on the clause 2.7 restructure. This page said “Amazon restructured 2.7 between those two dates”, meaning between our 9 and 22 August 2026 reviews. That is wrong: Amazon’s restructure took effect 25 November 2025, nine months before our first review, and our 9 August review simply missed it. The “UPDATED” dates on this page are OUR review dates, not Amazon’s change dates, and are now labelled as such.
- 2026-08-29: Corrected three word-frequency claims that decayed when Amazon restructured clause 2.7. We said the word “penetration” appears exactly once in the policy; it now appears five times, all inside 2.7. We printed the sub-clause headings as “2.7.1 Scanning”, “2.7.3 Remediation” and “2.7.4 Disaster Recovery”; Amazon prints “Vulnerability Scanning”, “Vulnerability Remediation” and “Disaster Recovery and Business Continuity”. The policy URL we cited now redirects, and is updated to the current canonical path. Verified against the live policy on 29 August 2026.
- 2026-08-22: Updated for Amazon’s restructuring of Data Protection Policy clause 2.7 into sub-clauses 2.7.1 to 2.7.4, effective 25 November 2025. Clause 2.7.2 now names an “industry-recognized methodology”, which it did not previously. Statements on this page about what Amazon does and does not publish were revised accordingly.
- 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.