Amazon’s Data Protection Policy clause 2.7.2 requires penetration testing at least every 365 days using an industry-recognized methodology, covering network infrastructure, cloud environments and application-layer assets including web applications and APIs. Amazon names no methodology, no approved vendor and no report format, which is exactly why an automated scan report is weak evidence: a scanner has no methodology to name and no tester to qualify. Amazon reviews and approves your developer profile and your compliance position. No testing vendor can approve it for you, and any vendor claiming otherwise is describing a programme that does not exist.
Say this part first
Amazon approves the submission. We do not. Amazon runs the developer profile review, the data security assessment and the architecture review, and Amazon holds the audit right in section 3 of the policy. Cybersecify produces the penetration test and the report that a reviewer or auditor reads.
The honest split is this. A vendor can commit to the report meeting Amazon’s published requirements. No vendor can commit to Amazon’s acceptance decision, because that also depends on what you remediate and on their reviewers. Coverage is what a testing vendor controls. The decision is Amazon’s. A vendor who describes their part as anything larger has already told you how they will behave when the report is inconvenient.
We have no approval rate to quote and we will not invent one. What we can show you is the shape of the work and the shape of the report, which is what you are actually buying.
This post answers a narrower question than what the DPP requires and who it binds, which is covered separately. The question here is what a qualifying test looks like, how to tell one from scanner output printed on a letterhead, and which parts of the policy a penetration test cannot evidence at all.
What clause 2.7 says today, quoted
We fetched the live policy on 21 August 2026. Amazon’s own changelog for the policy update records the current revision as effective November 25, 2025, covering network protection, access management, credential management, encryption, incident response, data retention, log retention, vulnerability management, audit cooperation and subcontractor requirements. The policy page itself carries no version number, so save a dated copy of the text you relied on.
Clause 2.7 is split into four sub-clauses. Here is 2.7.2 in full:
“Solution Provider must perform penetration testing at least every 365 days using an industry-recognized methodology. Penetration testing must cover systems that process, store, or transmit Amazon data, including: 1. Network infrastructure, including public-facing and internal network boundaries, firewalls, routers, and switches 2. Cloud environments, including cloud platforms and associated services and configurations 3. Application-layer assets, including web applications, APIs, databases and storage systems (file/object) 4. Other in-scope systems, as applicable (e.g., desktop applications or mobile applications)
Penetration testing must assess vulnerabilities across external-facing components, application functionality, access controls, system configurations, and interfaces.”
Three things in that text are worth slowing down on.
“Industry-recognized methodology” is a requirement, not a compliment. It is the only quality bar Amazon states, and it is stated about the method rather than the tool, the vendor or the price. A report that cannot name its methodology has not met the bar, whatever the testing behind it was worth.
“Access controls” and “application functionality” are named explicitly in the assessment sentence. Those are the two categories a scanner is structurally worst at, for reasons set out below.
Scanning is a different sub-clause. Clause 2.7.1 requires vulnerability scanning at least every 30 days, change-triggered scanning after significant network, application or infrastructure changes, and code scanning before each software release. Clause 2.7.2 is the pentest. If a scan closed the pentest clause, Amazon would not need two sub-clauses. Buying one and treating the other as covered is the most expensive misreading available here.
One thing we looked for and did not find. We searched the policy text for the words qualified and tooling on 21 August 2026 and found neither. The word tool appears once, in clause 2.6.1, and only as an example of a log-review mechanism (“e.g., SIEM tool”) , not as a testing-tool requirement. (Corrected 29 August 2026.) The nearest thing to a tester-quality standard sits outside the policy, in Amazon’s security control guidance: “Perform annual penetration testing using qualified security professionals or third-party firms and scan application code prior to each software release.” The word or is doing real work there, and it permits qualified in-house testing.
Why scanner output is weak evidence
Not useless. Weak, for this specific purpose. Three reasons.
A scanner has no methodology to name. It has a signature set and a crawl configuration. Neither maps onto anything a reviewer recognises as an industry methodology, which is why scan reports lead with a tool name and a scan date rather than a method and a scope. When clause 2.7.2 asks what methodology you used, “we ran a scanner” is a tool answer to a method question.
A scanner cannot see authorisation. This is the failure that matters most for SP-API, because your integration is multi-tenant by definition: many sellers, one application, one set of datastores. A scanner authenticated as seller A that reaches an object belonging to seller B sees a successful HTTP request. Nothing in the response is malformed. There is no error, no stack trace, no signature. The vulnerability is that the identifier belonged to somebody else, and knowing that requires knowing what should have been allowed. That is a human judgement about your business, and it is the finding that would end an SP-API integration if a seller found it first.
A scanner cannot chain. Real compromise usually runs through two or three findings that are individually unremarkable: an information disclosure that reveals an identifier format, a weak object reference that accepts it, a role check that is enforced in the interface but not in the API. Each scores low alone. Together they are an account takeover. Nobody is scoring the chain except a person who noticed it.
There is a fourth reason that is not about the scanner at all. If a web application firewall sits in front of your application, it can block the test traffic and produce a report that looks clean because the test never reached the code. The vulnerability is still there, the firewall merely hid it from your tester, and it will not hide it from an attacker who works around it. A tester who has not considered this may hand you a clean report that means nothing. We cover the general case in manual pentest vs automated scanning.
The SP-API surfaces a generic pentest will miss
This is where an SP-API engagement differs from a standard web application test, and it is the part worth checking in a scope document. Every requirement below is Amazon’s own published wording, and every one is a test case a person can run against your implementation.
The seller authorization workflow. Amazon’s website authorization workflow, accessed 21 August 2026, requires that your application “Generate a unique state token for each authorization request”, “Store the state token securely until Amazon’s response”, and “Verify that the state in Amazon’s response matches your stored value”. That is a cross-site request forgery defence on the flow that binds a seller’s account to your application. Whether it is implemented, and whether the verification actually rejects a mismatch rather than logging it, is a test, not a code review assumption.
Authorization code handling. The same page states: “The LWA authorization code (spapi_oauth_code) expires after five minutes. Exchange it for a refresh token before it expires.” A five minute window is a window. What your application does with an expired, replayed or reused code is worth knowing.
Token storage. Amazon states plainly: “Store tokens in a secure, encrypted database. Never store tokens in client-side code or logs. Never share or expose tokens in URLs.” Three specific negatives, all testable, and all of them things that appear in real applications through error handling, debug logging and support tooling rather than through the main code path.
Credential rotation. Amazon’s LWA credentials FAQ, accessed 21 August 2026, describes rotation as “the process of periodically updating your client secrets” and notes that “you can use your old LWA credentials for seven days after you rotate them”, while also warning that “In some cases, the credentials expire immediately after rotation, while in others, they may last up to seven days”. An application that cannot survive rotation loses SP-API access. That is an availability question your engineering team should have an answer to.
Restricted Data Tokens. Amazon’s RDT documentation, accessed 21 August 2026, explains that operations returning sensitive information including PII “are classified as restricted operations”, that RDTs “are specific to restricted operations and cannot be used for standard SP-API calls”, that you “pass the RDT in the x-amz-access-token header”, and that you must “Ensure that your application handles RDTs securely due to their access to sensitive data”. A test can check how RDTs are requested, scoped, logged and cached. What a test cannot check is your organisational commitment about what happens to the PII after it arrives, which belongs in the governance section below.
Encryption, with numbers Amazon publishes. From Amazon’s data encryption guidance, accessed 21 August 2026: encrypt all PII at rest “using industry best practice standards (such as using AES-128 bit or larger keys, AES-256 bit is preferred, or RSA with 2048-bit key size or higher)”; “Keys must be at least 128 bits in length”; “Rotate encryption keys at least annually and revoke compromised keys immediately”; and for transit, “Use HTTP over TLS 1.3 (HTTPS)”, enforced “on all applicable external endpoints that customers use as well as internal communication channels”. Note that the separate security control guidance sets the floor at “TLS 1.2 or higher”, so 1.2 is the minimum and 1.3 is what the encryption page directs you to. Amazon also states that Solution Providers “must not store PII in removable media (such as USB) or unsecured public cloud applications”.
One thing to keep out of your compliance document. We did not find rate limiting named as a requirement in the pages above. It is still worth testing, because an integration that can be driven at unbounded rate on behalf of one seller is an availability and cost problem. Keep it in the technical scope and out of the compliance citation. The same discipline applies to any vendor claim you cannot trace to an Amazon page.
What a pentest covers, and what it does not
This is the section most vendors leave out, and it is the one that decides whether your submission goes smoothly. A penetration test evidences implemented technical controls. It does not evidence governance. Both halves of clause 2 exist, and only one of them is a testing problem.
| Obligation | Can a pentest evidence it? |
|---|---|
| Access controls between seller accounts and between roles | Yes. Named in clause 2.7.2 and it is the core of the work |
| Application functionality, interfaces, external-facing components | Yes. Named in clause 2.7.2 |
| System configuration weaknesses on tested surfaces | Yes, within the agreed scope |
| Token storage, authorization workflow, credential handling as implemented | Yes, against Amazon’s published wording quoted above |
| TLS enforcement on tested endpoints | Yes, on the endpoints in scope |
| Encryption at rest key length and key rotation policy | Partly. A tester can observe evidence of it. Proving annual rotation happens is a records question |
| Vulnerability scanning every 30 days, code scanning per release, change-triggered scanning | No. Clause 2.7.1 is a recurring process, not a point-in-time test |
| 12 month log retention minimum | No. A retention commitment, evidenced by configuration and records |
| Incident response and notification timelines to Amazon | No. A process obligation with a clock attached |
| Data retention and deletion commitments | No. Policy and lifecycle work |
| Annual third-party risk assessment of vendors and subcontractors before granting access to Amazon data | No. The policy requires this in its own right |
| Geographically separated backup site with RTO and RPO targets, clause 2.7.4 | No. An infrastructure and continuity commitment |
| Patching cadence, including monthly manual updates where automatic updates are not supported | No. An operational cadence |
| Organisational commitments on how PII returned by restricted operations is used | No. This is a policy position, not a code path |
Read the right-hand column before you buy. If you go into a submission assuming the penetration test discharged your whole DPP obligation, the governance half is where it comes apart, and it will come apart in front of a reviewer rather than in front of us. Buy the test for the technical half and staff the governance half deliberately.
Staffing it yourself is a legitimate choice, and for a team that already runs an ISMS it is usually the right one. If you would rather not, the governance half is what our security audit and compliance readiness work covers: gap analysis against the clauses, the policies and procedures the policy expects you to have written, incident response and retention documentation, vendor risk, and the evidence pack that Section 3 turns into a records obligation. The full clause map on our main DPP page shows which half each clause falls in. Either way, decide it before the submission rather than during it.
What methodology-driven testing produces instead
This is what we do and what our reports contain. Every item is drawn from a real delivered report rather than from a capability page.
| What the report carries | Why it matters for a DPP file |
|---|---|
| Named methodology per surface: OWASP Web Security Testing Guide v4.2 applicable test cases, OWASP API Security Top 10 2023, OWASP ASVS with the level stated, PTES for the engagement lifecycle | The direct answer to “industry-recognized methodology” in clause 2.7.2 |
| A CWE on every finding | Gives the finding a classification a third party can look up, rather than a description only your engineers understand |
| CVSS v3.1 with the full vector on every finding, for example 8.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | Severity you can recompute and challenge. Clause 2.7.3 attaches a 7 day clock to critical and 30 days to high, so severity is a deadline, not a label |
| Reproduction steps and evidence per finding | Amazon’s guide requires the report to detail actions taken and vulnerabilities found. This is that, and it is how your engineers reproduce the issue without a call |
| A recommended actions section | Amazon states the tester must include one. It is the only report content requirement Amazon writes down |
| Business impact stated per finding | The reviewer is assessing risk to Amazon customer data, not counting issues |
| Role-aware testing across defined user shapes | Clause 2.7.2 names access controls explicitly. Testing one role does not test access control |
| A named lead assessor with a verifiable credential | Our reports name Rathnakara GN, OSCP, as lead assessor, with the certificate number, so the qualification can be checked against the issuing body rather than taken on trust |
| A retest delivered as a v2.0 report superseding v1.0, with per-finding remediation applied, retest method, observation, result and fresh evidence of the fixed state | Amazon’s guide requires a second test after remediation. A one line ticket comment does not evidence it |
The sample report shows the structure. Read it before you talk to us or to anyone else, because the structure is the part you can compare across vendors without being a security engineer.
On our side of the boundary this is web application testing and API testing, and where clause 2.7.2’s first bullet reaches network boundaries you manage yourself, internal network testing. Which of those belongs in your engagement depends on your architecture, not on a plan you pick off a page.
One report, and what a DPP engagement adds to it
The table above describes the report you receive. It is worth being explicit about what changes with the plan you buy, because “our reports include compliance mapping” is the kind of sentence that quietly means the cheaper option gets less of everything.
There is one findings schema and one core report. Every finding carries the same fields on every engagement: the finding ID and title, the scope and the affected endpoint, a severity band, a CVSS v3.1 score with the full vector, a CWE identifier and a second one where the weakness spans two classes, the OWASP category matched to the surface tested, a description, reproduction steps, evidence, business impact and a specific remediation. Every remediated finding carries a retest block recording what was applied, how it was re-checked, what was observed and the result, with fresh evidence of the fixed state. Every report carries an executive summary, the scope and methodology, a findings summary, a severity distribution, an appendix, a disclaimer, and a named lead assessor with their credential.
A Startup plan buyer receives all of it. Nothing in the core report is withheld by tier. A single-surface integrator on the smaller plan gets the same finding detail as a two-scope engagement. What the price difference buys is scope count, consulting hours, and the compliance layer below, not a better-written finding.
The compliance layer is what varies. On the Growth plan each finding also carries a mapping to SOC 2 Trust Services Criteria and ISO 27001:2022 Annex A controls, the report adds a compliance evidence package that turns those per-finding mappings around into control-to-findings matrices, and a Letter of Attestation is issued as a separate document after the retest so it reflects the remediated state.
For an engagement scoped to a DPP submission, a clause index. The same findings listed a second time against the sub-clauses of 2.7 they bear on, so the document reads in the order the policy is written rather than the order your application is built. It is the useful artefact for your file, because the file is organised by clause and your engineers are not.
One caution, since this is the part buyers most often over-read. An index changes how findings are presented, not what was tested. It adds no coverage. It does not close a clause by itself. And the coverage table earlier on this page still governs: every obligation marked “No” there stays outside a penetration test no matter how the report is indexed. The index saves you and a reviewer the reconciliation work. It buys nothing beyond that.
What to check with any vendor
Useful even if you hire someone else. These are the questions that separate a test from a scan with a cover page.
- Does the report show reproduction steps and evidence per finding, or just a severity label? Ask to see one finding in full from a redacted sample. A vendor who will only show a summary page is showing you what they have.
- Is severity a CVSS vector you can recompute, or an adjective? “High” is somebody’s opinion.
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Nis an argument you can check, and disagree with. - Is a retest included, and is it a full updated report or a one line note? Amazon expects a second test after remediation. Ask what the deliverable is, what it costs, and how fast it can run, because clause 2.7.3 gives you 7 days on critical findings.
- Will the report be readable by a third party who was not in your standups? The eventual readers are an Amazon reviewer, an auditor, or an enterprise customer’s security team. A report written for the engineers who sat in the kickoff will not survive that.
- Is the tester named, with a credential you can verify? Not “our team holds certifications”. A name, a certification, and a number you can check with the issuing body.
- Does the vendor claim they can get you approved? Nobody can. There is no Amazon-issued DPP certificate, no approved assessor list, and no pass or fail letter for the pentest control. The claim is the answer.
- Will the tester confirm a firewall was not masking results, and will that appear in the report? Most buyers never think to ask. A clean report produced by traffic that never reached your application is worse than no report, because you will act on it.
- Does the scope include the seller authorization workflow and token storage, or only the application screens? This is the SP-API specific one. If a vendor’s scope document could have been written for any web application, it was.
Where we fit, and where we do not
Clause 2.7 has four sub-clauses. We serve one of them well.
Penetration testing, 2.7.2: yes. Cybersecify does founder-led manual penetration testing for AI-first and API-first SaaS startups, with both founders hands-on in every engagement. A two scope engagement covering the integrating web 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, with 12 hours of founder-led consulting and one full retest within one month of the v1.0 report. A single-surface integrator fits the Startup Pentest at INR 74,999. Start at contact with your architecture rather than with a plan number.
Vulnerability scanning, 2.7.1: start with our free monthly scan, then fill the gaps. We run a free monthly external attack surface scan and email you the report, so the externally reachable half of the 30 day requirement has somewhere to go at no cost: see what the report contains or turn it on.
🔴 Read what that does and does not cover, because Amazon will. It maps what is reachable from the internet: subdomains and shadow infrastructure, open ports and exposed services, DNS and email authentication gaps, TLS posture, known CVEs prioritised with exploit-probability scoring. It does not scan inside your network, and it does not scan authenticated application surfaces. Clause 2.7.1 applies to the systems that store, process or transmit Amazon data, which for most integrations includes hosts our external scan cannot see. Pair it with your cloud provider’s native tooling, which Amazon’s own guide points at with Amazon Inspector, and you have the clause covered between the two.
Code scanning, 2.7.1: a pipeline job, and we will tell you what it has to produce. We do not sell SAST, DAST or IAST tooling or pipeline integration, and you should not buy it from a pentest firm. Amazon’s guidance names all three classes and expects the scan before every release, so your existing CI platform very likely does it already. Turn it on, gate the release on it, and keep dated output, because section 3 is a records obligation.
Remediation, 2.7.3: yours. We report and we advise, and the consulting hours bundled with each plan exist partly so remediation questions have somewhere to go. The fixing is your engineering team’s work, and the retest is how it gets evidenced.
Disaster recovery and the geographically separated backup site, 2.7.4: not a testing question at all. It is an infrastructure commitment with RTO and RPO targets attached. No penetration test closes it.
The governance obligations across the rest of section 2: not a testing question either. See the coverage table above. We will tell you which of your obligations our report does and does not touch, in writing, during scoping. That is a cheaper conversation than discovering it after a submission.
One document we do issue. After the pentest and the retest, we produce a Letter of Attestation as a separate document, so it reflects the remediated state rather than the original findings. Be clear about what it is: our statement about work we performed. Amazon does not require it and does not recognise it as a category. The written certification section 3 asks for, when Amazon asks, is a certification made by you about your own compliance, not one a vendor can make on your behalf.
What nobody can sell you. There is no DPP certificate. There is no approved tester panel. There is no pass letter. What exists is a records obligation, an audit right, and a review process Amazon runs. Your job is to be able to answer it, and a good report is the part of that answer you can buy.
Sources
Every Amazon page below was fetched and quoted on 21 August 2026. Amazon revises these documents, and the policy page carries no version number, so re-check before you rely on them. Note that developer-docs.amazon.com URLs currently redirect to developer-docs.amazon; both reach the same content.
- Amazon Services API Data Protection Policy, clauses 2.7.1 to 2.7.4 and section 3
- Updates to the Data Protection Policy and Acceptable Use Policy, effective 25 November 2025
- SP-API vulnerability management guide
- SP-API guidance to address key security controls
- SP-API protecting Amazon API applications: data encryption
- SP-API website authorization workflow
- SP-API authorization with the Restricted Data Token
- SP-API LWA credentials FAQ
- SP-API register as a public developer
- OWASP API Security Top 10 2023
- OWASP Web Security Testing Guide v4.2
Corrections
- 2026-08-29: Corrected two word-frequency claims. We said the Data Protection Policy “does not contain the word report at all”; it appears once, in clause 1.6.2, where it means reporting a Security Incident to Amazon rather than a pentest deliverable. We also said a search for “qualified”, “tool” and “tooling” found none of them; “tool” appears once, in clause 2.6.1, as an example of a log-review mechanism (“e.g., SIEM tool”). The substantive points stand: Amazon sets no report format and names no testing tool. The policy URL we cited now redirects, and is updated. Verified against the live policy on 29 August 2026.