Requirements checked: October 8, 2026
Amazon requires penetration testing at least every 365 days under the additional personally identifiable information (PII) requirements in its Data Protection Policy. For developers whose integrations handle PII, that means planning a pentest of the relevant application and supporting systems, then fixing the findings.
If you are preparing for an Amazon Selling Partner API (SP-API) security review, start by confirming your data access, testing scope, and submission deadline. This guide explains the requirements and how to prepare useful evidence.
Does Amazon SP-API require a penetration test?
The DPP separates general security requirements from additional requirements specific to PII. The annual pentest obligation appears in section 2.7.2, within the latter category. General controls still apply to integrations that do not handle PII.
Check the data your application retrieves and processes, the restricted roles it uses or requests, and any instructions in your Amazon review case. Avoid deciding applicability from the product label alone: an inventory dashboard and a shipping application may handle different data.
Token usage also needs context. In the Orders API v2026-01-01, approved roles provide PII access without Restricted Data Token (RDT) generation. An integration can therefore handle PII without using an RDT.
A pentest is part of the evidence you may need for review. Amazon's public developer registration guidance describes a broader assessment for restricted roles, including architecture, data flows, and PII protection. Your report should support that assessment alongside the relevant policies, diagrams, and operational records.
Testing frequency and remediation deadlines
For integrations subject to the additional PII requirements, the current policy specifies:
These requirements come from DPP sections 2.7.1 through 2.7.3. The remediation clock starts at discovery, so agree how urgent findings will reach engineering during testing.
Amazon's vulnerability management guidance also calls for a second pentest after remediation to validate the fixes. Reserve time for this before your submission deadline.
Significant changes explicitly trigger scanning. Additional pentesting after a major redesign is a sensible risk-based decision, even when the annual test is recent.
What should your SP-API pentest cover?
DPP section 2.7.2 requires an industry-recognized methodology and coverage of systems that handle Amazon data. Amazon's testing guidance identifies relevant network infrastructure, cloud environments, applications, APIs, and storage. Use your data-flow diagram to identify those systems and their dependencies.
For an SP-API integration, we recommend examining five areas:
- Seller authorization and credentials: How your application associates an authorization with the correct seller and protects Login with Amazon credentials, refresh tokens, access tokens, and RDTs where applicable.
- Application and API access controls: Whether users can access another seller's orders, exports, or shipping information by changing identifiers, switching organizations, or invoking functions outside their role.
- Background processing and integrations: Whether jobs, queues, imports, callbacks, and exports preserve the intended permissions as data moves between components.
- Data stores: How databases, object storage, backups, and administrative interfaces protect Amazon data, including copies created outside the main application.
- Cloud and network controls: Whether service permissions, exposed resources, configuration weaknesses, or internal access paths could compromise the integration.
This is where API penetration testing helps establish whether authorization works across real users, roles, and workflows. A working SP-API connection says little about whether your own backend enforces those boundaries.
Follow the data beyond the API. For example, an export may inherit correct seller permissions when it is generated but become accessible to other customers through a shared download URL. The application, export worker, and storage permissions all contribute to that exposure. Where the architecture warrants it, include cloud penetration testing and network penetration testing in the engagement.
Agree asset ownership and testing permissions before execution. Customer-hosted AWS resources are subject to the AWS penetration testing policy. That policy does not authorize attacks against Amazon's SP-API service itself.
Why a vulnerability scan is not the whole pentest
Scanning helps detect known vulnerabilities and configuration problems. Pentesting investigates whether weaknesses can be exploited in your application's context. Both activities have a place in the testing program.
For example, a scanner finding an outdated dependency does not answer whether a warehouse user can download another seller's customer addresses. That question requires suitable accounts, an understanding of the permissions, and testing of the application's behavior.
SP-API Guard can assess AWS configurations against DPP controls. Its results can inform preparation, but the configuration assessment does not establish that the annual pentest has been performed.
Blaze performs manual pentesting, with AI augmentation where it helps. Researchers direct the assessment, investigate application logic, and validate findings. Automation supports the work; the deliverable documents what was actually assessed and demonstrated.
What evidence should the report provide?
Amazon's vulnerability management guidance describes a report documenting testing activities, vulnerabilities, and recommended actions. Follow any additional evidence instructions in your review case.
For a useful submission, we recommend requesting:
- Scope and dates: The assets, environments, roles, and testing period, with exclusions and access limitations clearly identified.
- Methodology and coverage: The named methodology, how it was applied, and the systems and security boundaries assessed.
- Validated findings: Reproducible evidence, affected assets, severity, business impact, and practical remediation guidance.
- Fix validation: What was retested, when, and whether each finding was resolved or remains open.
An executive summary helps stakeholders understand the risks. Technical evidence helps engineering reproduce and fix them. Both should describe the assessed environment accurately.
Keep a findings register with the affected asset, discovery date, severity, owner, remediation deadline, fix evidence, and retest outcome. Retain the original findings alongside those records. A statement that testing occurred gives a reviewer less information than a report showing scope, results, and follow-up.
Our Amazon SP-API penetration testing service scopes this work around the integration and supporting systems. Agree the report and retest deliverables before testing begins.
Prepare your integration for Amazon's review
Before the assessment, give your testing team enough context to work efficiently:
- Share Amazon's request, the relevant roles, and your review deadline.
- Map Amazon data through the application, infrastructure, storage, and external dependencies.
- Provide API documentation and representative accounts for different sellers and user roles.
- Agree the environment, permitted techniques, access arrangements, and escalation contact.
- Assign engineering capacity for remediation and schedule fix validation.
Our API pentest preparation guide explains the documentation and access arrangements in more detail.
Check test accounts before the start date. If the team can authenticate but cannot reach order processing, exports, or administrative workflows, coverage will suffer. Resolve those access gaps while there is time to adjust the plan.
For evidence reuse, our SOC 2 pentest requirements guide explains why the framework and assessment scope matter.
Amazon's security control guidance refers to qualified security professionals or third-party firms.
Scope your SP-API pentest
If Amazon has requested testing evidence, bring your architecture, data access details, and review deadline to the scoping conversation. Blaze can assess the relevant systems through manual pentesting, using AI assistance where useful, and provide validated findings and agreed fix-validation evidence.
