By EJN Labs · 15 Sep 2026 · 8 min read
Not always. Amazon’s Selling Partner API Data Protection Policy requires annual penetration testing only for solution providers performing restricted operations that involve personally identifiable information, under Section 2.7. Applications that never touch PII sit outside that clause. Where it does apply, the policy also sets 30-day vulnerability scans and a 7-day fix window for critical findings; CREST-accredited testing satisfies the penetration-test requirement itself.
Why does Amazon’s Data Protection Policy show up in SP-API security reviews?
It shows up because SP-API access is conditional. Every application using Selling Partner API credentials must follow the Data Protection Policy, and losing that compliance can mean losing API access. Enterprise buyers treat the policy as the floor, then build their own questionnaire on top of it.
That second layer is where SP-API vendors commonly feel the pressure. A retailer or platform buying your integration usually wants a fixed answer before signing: a penetration test report, a coverage statement, and a named CREST-accredited firm behind it. We see this pattern constantly in supplier questionnaires that ask for third-party assurance requirements alongside confirmation of an OWASP-aligned methodology.
Two separate drivers land on the same desk: Amazon’s own policy, narrower than commonly assumed, and the buyer’s procurement bar, often wider. Getting each scope right avoids paying for testing Amazon never asked for, or under-delivering on what your customer needs to see.
Does the Data Protection Policy require a penetration test for every SP-API integration?
No. The mandate sits in Section 2, Additional Security Requirements Specific to Personally Identifiable Information, which applies once your application performs restricted operations that touch PII. Section 1’s general requirements, which bind every solution provider, contain no penetration testing clause at all.
Section 1 still matters for any SP-API build. It sets baseline controls: minimum 12-character passwords, multi-factor authentication on every account with access, encryption of stored SP-API credentials, and annual API key rotation. None of that is penetration testing, but a tester reviewing your environment checks these controls anyway, since a weak credential store undermines everything else.
Section 2.7, Vulnerability Management, is the clause that actually names testing. Once your application is classified as performing restricted PII operations, the policy requires a documented remediation plan, vulnerability scanning at least every 30 days, an additional scan after any significant change, code vulnerability scanning before each release, and a penetration test at least once every 365 days using an industry-recognised methodology.
| Requirement | What Section 2.7 sets |
|---|---|
| Vulnerability scanning | At least every 30 days, plus after significant change |
| Penetration testing | At least every 365 days |
| Code scanning | Before each software release |
| Critical vulnerability fix | Within 7 days of discovery |
| High-risk vulnerability fix | Within 30 days of discovery |
Which SP-API operations count as restricted for testing purposes?
Restricted operations are the SP-API calls that return, store or let your application act on personally identifiable information, such as order, shipping or buyer contact details reached through Amazon’s controlled data set. Requesting access to those operations is what triggers Section 2’s stricter regime.
In our experience scoping these engagements, the practical work is narrowing the annual assessment to the components that can actually store, process or control that data, not testing an entire platform end to end. For a multi-tenant SaaS product, that usually means the API layer, the OAuth authorisation flow, the order-data tables, and any export function that surfaces it. Components with no path to PII stay out of scope, keeping the engagement proportionate to what Section 2.7 actually covers.
How is testing scoped without sending attack traffic to Amazon or using real seller data?
By testing your application’s boundary, not Amazon’s platform. A tester exercises how your app calls SP-API, handles tokens and stores the response, using synthetic accounts and test data, never live production traffic aimed at Amazon’s own infrastructure or a real seller’s records.
In a multi-tenant application, that typically means tenant-isolation testing across two or more controlled test tenants, confirming that one customer’s credentials and data cannot be reached from another’s session. It also means testing the OAuth flow itself: token issuance, scope enforcement, refresh handling, and what happens if a token from one tenant is replayed against another. None of this touches Amazon’s own endpoints or a genuine seller account; it stays inside the systems you control.
Buyers who commission this kind of test commonly ask for manual, human-led testing supported by automated discovery, because a scanner-only assessment misses the logic flaws that matter most in a multi-tenant boundary, such as an authorisation check that works for one role but not another. We close the report with a coverage and limitations statement, so a procurement reviewer can see exactly what was and was not exercised.
What does Amazon SP-API penetration testing typically cost in the UK market?
UK day rates for CREST-accredited testing typically run £1,100 to £1,400. A focused test of the SP-API integration, OAuth flow and PII-handling components typically takes 4 to 6 days, so £4,400 to £8,400, with the exact figure set by scope.
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| SP-API integration, OAuth flow and PII-handling components only | 4 to 6 days | £4,400 to £8,400 |
| Full application plus SP-API integration and tenant isolation | 6 to 9 days | £6,600 to £12,600 |
| Application, API and cloud configuration review combined | 9 to 13 days | £9,900 to £18,200 |
| Remediation retest and closure report | 1 to 2 days | £1,100 to £2,800 |
These are typical UK ranges, not quotes; your actual price depends on how many tenants, roles and data stores the scope covers. Our guide to penetration testing costs in the UK sets out how effort and price scale more broadly, and an API penetration test is usually the closest match to the SP-API integration layer. Because Section 2.7 recurs annually, in our experience it is usually cheaper to keep the same scoped test on file than to re-negotiate coverage from scratch each year.
How EJN Labs approaches Amazon SP-API penetration testing
EJN Labs holds company-level CREST accreditation and ISO 27001 certification, and every engagement is delivered by UK-based testers, credentials that procurement teams commonly check before accepting SP-API evidence. When we scope an SP-API engagement, we start from the same question a buyer’s procurement team will ask: which parts of the application can actually store, process or control PII reached through the API, and what evidence you need once testing is done.
- Scoping against Section 2.7. We map your SP-API calls, OAuth flow and data stores against the restricted operations you actually use, so the engagement covers what the policy requires without testing features that never touch PII.
- Manual, human-led testing. Automated discovery feeds the assessment, but every finding that matters in a multi-tenant boundary comes from a tester working the logic by hand, not from a scan report.
- Tenant isolation as a first-class check. For multi-tenant SaaS, we test with controlled test tenants to confirm one customer’s data and tokens cannot be reached from another’s session.
- A closure report your buyers can read. The final report includes a coverage and limitations statement, and we include one remediation retest with an updated closure letter once fixes are in.
If you are comparing firms for this specific requirement, our guide to choosing a UK penetration testing provider covers the questions worth putting to any vendor, including us, before you commit an annual scope.
Frequently Asked Questions
Does Amazon SP-API require a penetration test for every application?
No. Section 2.7 of the Data Protection Policy applies only to solution providers performing restricted operations involving personally identifiable information. Applications that never request or store PII through SP-API sit under Section 1’s general controls, which include no penetration testing clause.
Does Amazon require the penetration test to be independent or third-party?
Not explicitly. Section 2.7.2 requires testing using an industry-recognised methodology at least every 365 days, but does not name who performs it. In our experience, enterprise buyers commonly ask for an independent test anyway, so many solution providers commission one regardless of the policy’s minimum.
What does Amazon SP-API penetration testing typically cost?
A focused test of the SP-API integration, OAuth flow and PII-handling components typically takes 4 to 6 days at £1,100 to £1,400 per day, so £4,400 to £8,400. Covering the full application and tenant isolation typically takes 6 to 9 days, or £6,600 to £12,600, with the exact price set by scope.
How often does the annual penetration testing requirement repeat?
At least every 365 days once your application is in scope, alongside scans at least every 30 days and a scan before each release. Critical vulnerabilities need fixing within 7 days of discovery and high-risk ones within 30 days, so the annual test is one part of a continuous cycle, not a one-off event.
Is a scanner-only assessment enough to meet the requirement?
Rarely, in our experience. Section 2.7 names penetration testing separately from scanning, and buyers who commission this work commonly ask for manual, human-led testing supported by automated discovery, stating plainly that a scanner-only assessment is not sufficient for logic flaws like broken tenant isolation.
Get CREST-accredited evidence for your SP-API compliance file
If Amazon’s Data Protection Policy or a buyer’s questionnaire is asking for penetration test evidence, tell us about your SP-API surface, tenants and OAuth flow and we will scope it properly rather than sell you a generic package. Get a CREST pentesting quote to start that conversation.
Leave a Reply