By EJN Labs · 16 Sep 2026 · 6 min read
Amazon’s Selling Partner API Data Protection Policy requires annual penetration testing only from solution providers whose applications perform restricted operations involving personally identifiable information. Section 2 requires an industry-recognised methodology that covers every system touching Amazon data and permits qualified internal professionals or a third-party firm to run it. Amazon does not certify any individual tester or firm; what matters is the evidence the report provides.
Why penetration testing evidence matters for restricted SP-API operations
Penetration testing evidence matters because personally identifiable information changes Amazon’s risk view of your application. The moment your integration can return buyer or seller PII, Section 2 of the Data Protection Policy adds obligations beyond the baseline rules every provider carries.
SP-API defines this technically rather than loosely. A restricted operation is any call that needs a Restricted Data Token, and Amazon’s own guide lists exactly which endpoints across the Orders, Direct Fulfillment, Shipping and Reports APIs fall into that category. Section 1 of the policy covers baseline controls such as encryption, logging and 24-hour incident notification, and applies to every solution provider regardless of what their application does. Section 2 only switches on once your application is authorised to request that token, which is precisely when penetration testing stops being optional.
For a UK software vendor selling tools into the Amazon marketplace, this split typically arrives through feature creep rather than a deliberate decision. An integration that started out reading product listings adds an order-sync or customer-messaging feature, and without anyone flagging the change, the application now needs a Restricted Data Token and inherits Section 2 in full.
What counts as a restricted operation involving PII
Restricted operations are any SP-API call that returns personally identifiable information about buyers or sellers, such as names or delivery addresses. Calling one requires a Restricted Data Token, and holding that authorisation brings Section 2’s penetration testing obligation into force.
If your application only handles product listings, pricing, inventory or catalogue data, it never calls a restricted operation and Section 2 does not apply, however thorough your Section 1 controls need to be. The line is not about your company’s size or how much PII you handle overall. It is about whether a single API call in your integration is capable of returning it, which is why teams that added order-sync or messaging features are commonly the ones who discover they have quietly crossed into Section 2.
What the annual assessment has to cover
The annual assessment has to cover every system that processes, stores or transmits Amazon data: your public-facing and internal network boundaries, cloud environment and configuration, and the application layer itself, tested against an industry-recognised methodology rather than an automated scan alone.
This is functionally the same scope as a standard API penetration test, extended to include the network boundaries and cloud configuration Section 2 also names. It also needs to be manual, human-led testing supported by automated discovery, not a scanner-only assessment, and the policy sets two remediation clocks: seven days for critical-risk findings and thirty days for high-risk ones, both measured from the date of discovery rather than from report delivery.
How the evidence trail runs from scoping to closure report
The evidence trail starts with a scoping call that identifies exactly which components can store, process or control PII, then moves through structured testing, a written report and a validation retest once fixes land. The closure report at the end is what confirms remediation, not just findings.
Because the endpoints in scope sit behind Amazon’s own infrastructure, testing is designed around your application’s boundaries and its OAuth flow, without sending attack traffic to Amazon or using real seller data. We test against a sandbox or staging environment seeded with representative, non-production records, then map every finding back to the specific restricted operation it affects, so remediation work is targeted rather than generic.
What an SP-API-scoped penetration test costs in the UK market
An SP-API-scoped penetration test typically costs £3,300 to £7,000 in the UK market for an API-only assessment across 3 to 5 days, rising to £7,700 to £14,000 across 7 to 10 days once network and cloud configuration are added, at typical UK day rates of £1,100 to £1,400.
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| SP-API integration only (API endpoints, OAuth flow) | 3 to 5 days | £3,300 to £7,000 |
| SP-API integration plus supporting web application | 5 to 8 days | £5,500 to £11,200 |
| Full Section 2 scope: API, network boundaries and cloud configuration | 7 to 10 days | £7,700 to £14,000 |
| Remediation retest | 1 to 2 days | £1,100 to £2,800 |
These are typical UK ranges rather than quotes; your exact price depends on how many restricted operations your integration calls and how much of the wider network and cloud environment falls in scope. For a broader picture of what drives UK testing prices, see our guide to penetration testing costs in the UK.
How EJN Labs approaches SP-API penetration testing evidence
EJN Labs is a CREST-accredited UK penetration testing firm, certified to ISO 27001 and Cyber Essentials Plus, with every test carried out by UK-based testers. We scope each engagement around the restricted operations your application calls, so the report maps to your actual Data Protection Policy obligation.
Where a solution provider is weighing an internal team against an outside firm, both routes are permitted under Section 2 of the policy. What an independent CREST-accredited report adds, in our experience, is evidence your own partners and customers can rely on without re-testing your claims themselves, alongside the coverage and limitations statement, retest and closure report a buyer’s compliance team commonly asks to see.
Frequently Asked Questions
Does every Amazon SP-API solution provider need an annual penetration test?
No. Section 2 of the Data Protection Policy only requires the annual penetration test for solution providers whose applications can call a restricted operation and return personally identifiable information. If your integration never touches PII, only Section 1’s baseline controls apply to you.
Can our internal security team run the test, or does it have to be a third-party firm?
Either. Amazon permits the annual test to be run by qualified internal security professionals or a third-party firm, with no requirement for external independence. Outside firms are commonly chosen anyway, for the objectivity and evidence they add for customers and partners.
Do we need a coverage and limitations statement for our annual assessment?
A coverage and limitations statement is not named in the Data Protection Policy itself. In our experience it is standard practice to include one: the systems in scope, anything excluded and why, and the methods used, since that is often the first detail a buyer or reviewer asks to see.
Does a vulnerability scan satisfy the annual penetration test requirement?
No. The policy treats vulnerability scanning and penetration testing as two separate obligations on different clocks: scans at least every 30 days, penetration tests every 365 days. A clean scan does not remove the annual test requirement, which by nature is manual, human-led testing, not an automated pass.
What does an SP-API-scoped penetration test cost in the UK?
CREST-accredited testers in the UK market typically charge £1,100 to £1,400 per day. An API-only SP-API assessment usually takes 3 to 5 days, so £3,300 to £7,000; adding infrastructure and cloud configuration takes it to 7 to 10 days, or £7,700 to £14,000. Exact pricing depends on scope.
Get evidence ready before your next Data Protection Policy review
If your application is moving toward a restricted operation and PII, we can build a fixed-scope assessment around your Section 2 obligations, from the coverage and limitations statement through to the retest and closure report. Get a CREST pentesting quote and we will come back with a scope and price for your SP-API integration.
Related research
For the underlying mandate question, see our guide to whether the Amazon SP-API requires a penetration test. For the exact scan and remediation cadence Section 2 sets, see Amazon SP-API vulnerability management. And for how platform-run security reviews differ from a penetration test more broadly, see marketplace security reviews versus penetration tests.
Leave a Reply