Yes, if your application holds a restricted role. Clause 2.7.2 of Amazon’s Data Protection Policy requires penetration testing at least every 365 days, and that clock runs on the test rather than on the submission. So a reassessment needs a test performed inside the previous 365 days. The report you filed last time stops satisfying the clause once it is older than that.
Two conditions decide whether any of this binds you, and they are worth checking before you buy anything. Clause 2.7.2 sits inside section 2 of the policy, headed “Additional Security Requirements Specific to Personally Identifiable Information”. Section 1, the General Security Requirements every Solution Provider must meet, contains no penetration testing clause at all. So the obligation follows the restricted roles. And Amazon never asks you to submit the report: section 3 requires you to hold records and to certify compliance in writing when asked.
Which restricted roles, and the full clause text, are set out on our SP-API DPP pentest pillar. This page is about the renewal specifically: what has changed under you since you were last assessed, and which parts of it a test cannot evidence.
What changed under you
Amazon restructured clause 2.7 and rewrote parts of the policy on 25 November 2025, then revised it again effective 25 August 2026. Put that beside a 365-day clock and a specific group has a problem nobody has told them about:
If your last DPP penetration test ran before 25 November 2025, your next one is against a policy that has materially changed twice since.
The arithmetic is worth doing explicitly. A test on 20 November 2025 falls due around 20 November 2026. A test in March 2025 fell due in March 2026. Anyone whose previous assessment predates the rewrites is renewing against requirements that did not exist when they were last assessed.
What the 25 November 2025 revision added or tightened, per Amazon’s own changelog:
| Area | What was added or tightened |
|---|---|
| Network protection | Controls to prevent anti-virus and anti-malware software being disabled |
| Access management | Account lockout after ten unsuccessful login attempts |
| Credentials | Password history retention for the last ten passwords, and API key rotation |
| Encryption | TLS 1.2 or higher, and Key Management System implementation |
| Incident response | A designated, readily available Incident Management Point of Contact |
| Data retention | Non-PII retained only as long as strictly necessary, with the business purpose documented |
| Log retention | Minimum raised to 12 months |
| Vulnerability management | Critical in 7 days, high-risk in 30, plus geographically dispersed backup requirements |
| Third parties | Subcontractor risk assessments now required |
| Terminology | ”Developer” renamed “Solution Provider” throughout |
🔴 One note on the retention row, because two Amazon sources word it differently. Amazon’s changelog summarises the non-PII change as an 18 month cap. The policy text itself does not use that figure: it requires retention “only for as long as, and to the extent, retention is strictly necessary” with the business purpose documented. We have stated it as the policy states it, because the policy is what binds and the changelog is a summary of it. If you are scoping against a number, read the live clause rather than the announcement.
The 25 August 2026 revision then added a further set, covering endpoint and device hardening, credential handling, a deletion window, a named incident contact, and an expansion of the scanning and penetration testing requirements. The pillar sets that revision out in Amazon’s own words, together with the only available way to tell which revision you are holding: the second revision, effective 25 August 2026.
🔴 The one line from it that changes a renewal scope is the testing clause. The expansion names Application Programming Interfaces explicitly inside the application-layer category. So the question to ask of your previous engagement is narrow: was the API in scope, or was it treated as part of the web application? If it was the latter, that is a scope gap on renewal rather than a finding, and it is cheaper to fix at scoping than after a reviewer raises it.
Roughly half the list is not findable by a penetration test
This is the part that catches renewal buyers, and it is the single most useful thing on this page.
What a test can evidence, because it is observable in a running system: TLS 1.2 or higher in use, account lockout behaviour after failed attempts, Key Management System usage, the presence and configuration of a web application firewall, and the application, API, cloud and network controls clause 2.7.2 names.
What a test cannot evidence, because it is a record rather than a behaviour: password history retention, the 12-month log retention minimum, the designation of an Incident Management Point of Contact, documented business purposes for non-PII retention, and the annual third-party risk assessments of vendors and subcontractors that clause 2.8 requires before granting them access to Amazon data.
A tester can observe that a control appears to be present. A tester cannot evidence that your organisation maintains it.
So a renewal handled as “book the same test as last year” can produce a clean penetration test report and still leave the assessment short. The sequence that works is a gap review against the current policy text first, and the test scoped from that. Our SP-API DPP evidence checklist sets out the eight areas Amazon asks a Solution Provider to evidence and marks which ones a penetration test produces for you: one of the eight fully, three partly, and four that are not testing problems at all.
The clock you are actually working against
Work backwards from the date your current test was performed, not from the date you submitted last time.
Then allow for three things that sit between a kickoff and a finished report. Testing and reporting take time: we quote 6 business days per scope, 5 testing and 1 writing the report, so a four-category scope is not a one-week job. Remediation usually takes longer than testing, and clause 2.7.3 sets its own windows of 7 days for critical findings and 30 days for high. And Amazon’s vulnerability management guidance requires a second test after remediation to validate the findings are closed, which makes the retest part of the work rather than an optional extra.
A reassessment started a month before the anniversary is tight. Started three months before, the remediation window stops being the binding constraint.
The scanning clock runs separately, and monthly
Clause 2.7.1 is a different obligation on a different cadence: vulnerability scanning at least every 30 days, change-triggered scanning after significant network, application or infrastructure changes, and code scanning before each release. An annual test cannot satisfy a 30-day cadence, and the two clauses need two different activities. We cover that separately in what the 30 day scanning requirement actually asks for.
Where we fit
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 the business days for a three and a four scope engagement.
What no vendor can do, including us: 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. Amazon decides submissions and we are not in that room. What exists is a records obligation and an audit right, and the job is to be able to answer it.
Request the SP-API DPP evidence checklist. It sets out all eight evidence areas, who produces each one, and which a penetration test evidences for you. Sent on request, read by a founder first.
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.7.1, 2.7.2, 2.7.3, 2.8 and section 3 at sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US, read 17 October 2026 against the revision effective 25 August 2026. Amazon’s SP-API changelog entry “Updates to the Data Protection Policy and Acceptable Use Policy”, effective 25 November 2025. Amazon, “Announcement for Policy Update”, developer.amazonservices.com/policy-update-for-sp-api. Restricted role list at developer-docs.amazon/sp-api/docs/roles-in-the-selling-partner-api, five roles, read 17 October 2026. Second-test-after-remediation requirement at developer-docs.amazon/sp-api/docs/vulnerability-management. The live policy page carries no version number and no effective date, so save a dated copy of the text you relied on.