Amazon SP-API DPP Checklist + Pentest Evidence Templates

Access to Amazon’s Selling Partner API comes with a condition: pass the Amazon data security assessment, and make sure the pentest report at the center of it says what you think it says.

Most of the trouble we see isn’t weak security, but rather a mismatch between what was tested and what the report claims was tested. One team’s report listed its scope as Web App. The assessor flagged it, and the team spent time proving in writing that the APIs had been covered too.

This guide thus maps Amazon’s Data Protection Policy (DPP) to the evidence an assessor expects to see, with fill-in templates for the pentest executive summary and engagement letter via an Amazon SP-API DPP checklist. Amazon decides whether an application meets its requirements through its own security-assessment process, and no vendor can promise approval. We won’t either.

How the Assessment Works, and Where the Pentest Fits

In simple terms, what applies to you from the Amazon SP-API DPP checklist, depends on your role.

While a pentest report tells an assessor the application was tested properly, it doesn’t say anything about how you encrypt backups, who can still log in after leaving, or what happens in the first hour of an incident.

Note: Be careful not to just pour effort into the test and leave the rest until the assessor asks.

Some such requirements that shape the pentest and possibly its scope the most include:

Most people read the August update too late. It extended pentest and scanning expectations to APIs and added the WAF, credential-encryption, and incident-contact requirements. Continued use of SP-API counts as accepting it, so check any report scoped before 25 August against the new language before it goes to an assessor.

Amazon does offer a voluntary self-assessment questionnaire under Policies and Agreements, which can be a useful internal readiness exercise, but it doesn’t replace the formal assessment with a control map to list each DPP control against an owner, current state, evidence location, gap, and due date.

Amazon SP-API DPP Checklist

Treat this as a working list. Amazon’s wording changes, so confirm it against your own assessment request.

1. Access management

Access is limited to authorized personnel, removed promptly when someone leaves or changes role, and revoked for unused or compromised programmatic access. 

Amazon’s updated policy explicitly requires a 30-minute lockout after ten failed login attempts. Multi-factor authentication is a strong supporting control, but confirm the exact requirement in your own assessment request before presenting it as mandatory. 

Some of the key evidence you’ll need includes:

• Access-review log
• Joiner-mover-leaver procedure
• Export or screenshot of role assignments
• Offboarding ticket
• API key and token revocation record
• MFA and lockout configuration

2. Encryption

Encrypt PII at rest with AES-128 or stronger (AES-256 preferred), or RSA-2048 or stronger. SP-API credentials must also be encrypted at rest and stored securely. Teams tend to evidence one of these and forget the other.

Some of the key evidence you’ll need includes:

• Encryption configuration for databases, disks, backups, and object storage
• KMS, i.e., key-management evidence, plus TLS configuration
• Secret-manager inventory and a code search showing no hardcoded credentials
• Key-rotation policy
• Cloud configuration review for the platforms you run on.

Note: In our experience, assessors have asked for this to back up encryption, MFA, lockout, and WAF claims, even if cloud config review isn’t a named Amazon requirement.

3. Logging and monitoring

Log every channel that provides access to information, protect the logs from tampering, and test your alerting. An alert that has never fired in a test is an assumption.

Some of the key evidence you’ll need includes:

• Log-retention policy
• Centralized log sample
• Alert-rule export and an alert test record
• Access-control settings on log stores

4. Incident response (24-hour notice)

Amazon expects a senior-management-approved plan, reviewed every six months, with defined roles, escalation paths, and a named incident contact (IMPOC). Notice goes to [email protected] within 24 hours of detection.

Some of the key evidence you’ll need includes:

• Approved plan with a review sign-off within the last six months
• IMPOC name, role, email, and phone, confirmed current and shared with Amazon
• Escalation path and contact list
• Incident ticket template
• The 24-hour notification procedure
• Incident documentation, remediation actions and corrective controls, retained so they can be produced on request
• Evidence of tabletop or operational testing

5. Retention and deletion

Delete information within 30 days from live stores, backups, and other copies to keep your PII exposure low. Anonymization or hashing doesn’t count.

Some of the key evidence you’ll need includes:

• Data-retention schedule
• Deletion job logs
• PII inventory or data-flow map
• Deletion verification across live systems and backups

6. Vulnerability management

Amazon wants a pentest within the last 12 months, scans on a 30-day cycle and after significant changes, and critical and high findings closed within 7 and 30 days, with a retest to show it.

Some of the key evidence you’ll need includes:

• Pentest report from the last 12 months, naming the methodology
• Scan reports every 30 days and after significant changes
• Code scans before each release
• Tickets showing critical and high findings closed on time
• Retest results
• A recommended actions section in the report

7. Backups and disaster recovery

Documented procedures to restore PII availability, a geographically separated backup site, defined RTO and RPO, and restore tests that are actually documented.

8. Network and endpoint controls

Firewalls, anti-malware, secure connections, a WAF on internet-facing endpoints, device-storage encryption, screen lock and failed-login lockout.

Some of the key evidence you’ll need includes:

• WAF configuration
• Firewall rules
• Endpoint policy and MDM or device-encryption evidence
• Lockout configuration

The Pentest Evidence Pack

While Amazon doesn’t prescribe a report format, the evidence pack you submit should be able to answer the assessor’s questions before they ask them. In practice an ideal pentest evidence includes:

1. A signed, dated executive summary
2. An engagement letter with test dates
3. A named methodology (OWASP WSTG, PTES and NIST SP 800-115 are the usual ones), with manual and automated testing both stated
4. A scope listing every asset, including APIs, databases, and object storage
5. Findings by severity
6. Remediation status
7. Limitations and exclusions
8. Tester names and authorization
9. Retest results
10. Recommended actions

Pro tip: The exact production URLs and asset identifiers from your Amazon submission should appear in the report and any supporting evidence. Any mismatch between what you submitted and what was tested invites questions and inevitably a longer timeline.

Template: Executive Summary

Copy this into your own document and fill in the brackets. The testing firm should complete and sign it. This is a working format, not an Amazon-issued form, and a pentest lead should review it before you submit it for a final review.

PENETRATION TEST EXECUTIVE SUMMARY

Client/Solution Provider: [Company legal name]

Application/System: [Product or system name]

Amazon SP-API App ID (if applicable): [App ID]

Test period: [Start date] to [End date]

Report date: [Date]

Report version: [v1.0]

Testing organization: [Firm or internal team]

Lead tester: [Name, title]

Tester(s): [Names]

Authorization: [Engagement letter reference / approver name and date]

Business objective:

[One or two sentences on the system, its SP-API integration,

and the purpose of the assessment.]

Scope tested:

• Web application: [URL(s) / environment(s)]
• APIs: [Public endpoints, SP-API integration endpoints, admin APIs]
• Cloud environment: [Account(s), services, regions]
• Databases: [Types and environments]
• Object/file storage: [S3 buckets or equivalent]
• Network boundaries: [External-facing systems, firewalls, VPNs]
• Exclusions: [Assets, environments or attack types excluded]

Methodology:

[Named methodology, e.g. OWASP WSTG / PTES / NIST SP 800-115, and phases:

planning, discovery, exploitation, analysis, reporting, remediation

validation. State that testing combined manual and automated techniques.]

Overall result:

[Pass / Pass with observations / Fail]

[One-paragraph plain-English conclusion.]

Findings summary:

Critical: [n]  High: [n]  Medium: [n]  Low: [n]  Informational: [n]

Key risks:

1. [Finding title – severity – business impact]

2. [Finding title – severity – business impact]

3. [Finding title – severity – business impact]

Remediation status:

[All critical/high remediated and retested / exceptions listed below]

Retest date: [Date]

Retest result: [Pass / outstanding items]

Recommended actions:

[List]

Limitations:

[Constraints, credentials, excluded systems, time window]

Sign-off:

Tester name/signature/date: ______________________

Client approver name/signature/date: ______________

Template: Engagement Letter

Like the summary, this should come from the testing firm. It records who tested, what was covered, and when.

PENETRATION TESTING ENGAGEMENT LETTER

Date: [Date]

Client: [Company legal name]

Address: [Address]

Authorized representative: [Name, title, email]

Testing provider: [Company or individual]

Lead tester: [Name, title]

Contact: [Email / phone]

1. Purpose

[Testing provider] will perform a penetration test of [system/application]

to identify exploitable security weaknesses and provide remediation guidance.

2. Authorization

The Client authorizes testing of only the systems and assets listed below,

during the agreed window and within the agreed scope.

3. Test window

Start: [Date/time, timezone]

End: [Date/time, timezone]

Emergency stop contact: [Name, phone, email]

4. Scope

In scope:

• Web application: [URLs / environments]
• APIs: [Endpoints, including SP-API-facing endpoints]
• Cloud environment: [Accounts, services, configurations]
• Databases: [Systems and environments]
• Object storage: [Buckets / storage services]
• Network components: [Firewalls, routers, VPN endpoints]
• Mobile/desktop applications: [If applicable]

Out of scope:

• [Third-party SaaS, payment processing, physical sites, etc.]
• [Prohibited attack types, e.g. DoS, destructive testing, social engineering]

5. Methodology

Testing will follow: [OWASP WSTG/PTES/NIST SP 800-115/other].

Activities may include reconnaissance, vulnerability identification,

controlled exploitation, configuration review, API testing and reporting.

6. Data handling

The testing provider will not retain, disclose or use Client data except as

necessary to perform and document the engagement. Evidence will be stored

securely and deleted or returned according to: [retention/destruction terms].

7. Deliverables

• Scope confirmation
• Penetration test report and executive summary
• Findings and remediation recommendations
• Retest report, where applicable

8. Confidentiality

Both parties will keep engagement details, findings, credentials and data

confidential except where disclosure is legally required or authorized in writing.

9. Signatures

Client authorized representative: ______________  Date: ______

Testing provider authorized representative: ______  Date: ______

Before submitting the same, do have some qualified legal and security professionals review this to confirm  scope boundaries, rules of engagement, emergency contacts, data handling, liability and jurisdiction language, and whether you need an engagement letter, a statement of work, or a rules-of-engagement document.

Scope Wording that Won’t Get Flagged

Most scope problems come down to vague wording issues, i.e.,  a scope that says Web App leaves the assessor to guess whether the APIs were tested, and they will ask for written proof.

The solution is simple: name every asset class, and name it the way your submission does.

Sample scope statement

In scope: the production web application at https://app.example.com, its REST APIs, SP-API integration endpoints, AWS environment 123456789012 in us-east-1, associated RDS/PostgreSQL databases, S3 buckets storing seller or order data, IAM policies and cloud configuration, and public-facing network boundaries.

Sample API coverage statement

API testing here addresses authentication, authorization, object-level access control, injection, mass assignment, excessive data exposure, unrestricted resource consumption, security misconfiguration, and inventory and versioning risks, consistent with the OWASP API Security Top 10.

Have your pentest lead confirm the exact wording against your own submission.

Scan Evidence: Keep the 30-day Logs

Scans are the part teams forget. Amazon expects them at least every 30 days, after significant network, application, or infrastructure changes, and as code scans before each release. A fix deadline only means something if the log shows when the finding was detected and when it was closed.

Reconstructing six months of scan history in the week an assessor asks for it is where gaps appear, and human error peaks as they become harder to explain months after the fact. Instead, collect the data as you go, keep the raw scanner output, remediation tickets, change requests and retest evidence, not just the final PDF.

How Astra can Help

An SP-API pentest is a scope and evidence exercise, so we build ours that way. Scope is named to the DPP: web app, APIs, cloud, databases, and storage.

You get a signed, dated executive summary, an engagement letter with test dates, and a retest. AI-powered testing starts within 24 hours while certified human pentesters run the manual work. Amazon decides the outcome. We make sure the evidence holds up.

Get started today!

Final Thoughts

The August update is a useful reminder that the SP-API bar moves. APIs were added to the pentest scope, a WAF and a named incident contact became requirements, and anyone who kept using the API accepted all of it without a form to sign.

The next revision will probably tighten something else, and a team that scrambles for evidence every time will always be a step behind it. The ones who cope best treat the assessment as a by-product of how they already work, so nothing has to be reconstructed when Amazon asks.

None of that is hard, but it does mean someone has to own it before the deadline is tomorrow. Security that can’t be shown to an assessor is, for the purposes of keeping API access, security you haven’t got. A penetration test report template is only as good as what it lets someone else verify, which is the best reason to get the paperwork right.

FAQ