Amazon SP-API Vulnerability Management: 30-Day Scans, Annual Penetration Tests and 7-Day Remediation

Why Amazon treats SP-API vulnerability management as an ongoing programme

Amazon ties continued SP-API access to an ongoing cadence, not a single pass-or-fail moment. Miss a scan, skip a code check, or let a critical finding run past its deadline, and the same compliance exposure applies as never testing at all.

That cadence lives inside Amazon’s Data Protection Policy vulnerability management requirements, which switch on once an application performs a restricted operation returning personally identifiable information, buyer names and delivery addresses pulled through the Orders or Reports APIs being the obvious example. UK repricing, order-management and fulfilment tools sit squarely in that category.

The four obligations that make up the vulnerability management cadence

Four separate clocks run at once. Vulnerability scans repeat at least every 30 days, and again after any significant network, application or infrastructure change. A penetration test using an industry-recognised methodology repeats at least every 365 days. Code is scanned for vulnerabilities before every release, and critical-risk findings carry a seven-day resolution deadline, high-risk ones 30 days, both counted from discovery.

Whether any of this applies to you comes down to one question: does your application call a restricted operation that can return PII. We cover that scoping question in full in our companion piece on whether Amazon SP-API requires a penetration test; here we assume the answer is yes.

Structurally, the annual test itself is scoped like a standard API penetration test, extended to cover the network and cloud layers the DPP also names.

Running the 30-day scan and pre-release code scan without a fire drill

The two highest-frequency obligations are also the two most likely to get automated and then forgotten. Scanning tools such as Amazon Inspector for AWS-hosted workloads can run the 30-day cycle unattended, and most CI/CD pipelines can bolt on a code scan as a release gate. The risk is rarely the tooling; it is nobody owning the finding once the tool produces one.

In our experience, the gap that causes problems is not the scan but the queue behind it: a scanner running quietly for months while its output sits unread, so a finding from week one is still open in week twelve. A programme built around the DPP’s cadence needs an owner for that queue, not just the tool switched on.

Meeting the seven-day and 30-day remediation windows without missing a release

Amazon counts both remediation windows from the date a vulnerability is discovered, not from when a fix ships or a report is signed off. A critical finding surfaced by Tuesday’s scan is already five days into its seven-day window before a Friday release reaches code freeze, so remediation has to run ahead of the normal sprint cycle rather than inside it.

We have not seen Amazon publish a stated penalty for a missed window specifically; what the documentation ties compliance failures to generally, across the whole policy, is continued SP-API access. Treating the seven-day and 30-day clocks as release-blocking deadlines, rather than best-effort targets, is the safer default for anything client-facing.

Turning the annual test into a signed independent attestation suitable for third-party security review

The annual penetration test produces more than a compliance tick for Amazon. Retail and marketplace buyers running their own supplier questionnaires commonly ask for the same evidence in a different wrapper: a signed independent attestation suitable for third-party security review, not just an Amazon-facing report. Scoping the engagement once, with both audiences in mind, avoids commissioning two separate tests.

That reuse only works if the report travels: a clear scope statement, findings mapped to severity, evidence of remediation and a validation retest, with accreditation stated plainly enough that a reviewer who has never heard of the DPP can still act on it. We build every SP-API report this way by default.

Budgeting across the scan, test and remediation cadence

The 30-day scanning and pre-release code scanning obligations are usually the cheapest line items, since both run on automated tooling once configured and add marginal cost per cycle rather than a day-rate fee. The annual penetration test is where day-rate pricing applies, and UK CREST-accredited rates for this kind of work typically sit at £1,100 to £1,400 a day.

A single SP-API integration tested at the application layer alone typically takes 5 to 6 days, so £5,500 to £8,400. Extending that to the cloud environment hosting the integration, AWS or GCP configuration included, moves it to 8 to 9 days, or £8,800 to £12,600. A fuller estate covering the integration, the cloud environment and a seller-facing web dashboard together typically runs 11 to 13 days, so £12,100 to £18,200. Amazon’s own guidance also calls for a second, validation-focused test once remediation is complete; budget 2 to 3 days for that pass, or £2,200 to £4,200.

Treat these as UK market planning figures rather than a quote; a scoping conversation sets the real day count once we know how many of the DPP’s asset categories your application spans. Our penetration testing cost guide sets out how those figures scale for other types of engagement.

How EJN Labs approaches Amazon SP-API vulnerability management

EJN Labs runs SP-API vulnerability management as a standing programme, not a single deliverable: we scope the annual test, time the code-scan gate against your release cycle, and track remediation against the seven-day and 30-day clocks so nothing slips past its window.

Our accreditation covers the whole engagement: CREST at company level, ISO 27001, and Cyber Essentials Plus, delivered throughout by UK-based testers so seller and buyer data never leaves the UK. Every annual test includes one validation retest once fixes land, closing the loop the DPP itself calls for.

Because the same report has to satisfy Amazon’s own compliance check and whichever buyer questionnaire lands next, we write findings and remediation evidence so they stand on their own, without assuming the reader already knows the DPP’s clause structure.

Frequently Asked Questions

What counts as a significant change that triggers an extra vulnerability scan?

A significant change is anything that alters your network, application or infrastructure: a new server, a changed firewall rule, or a dependency upgrade. Amazon sets no numeric threshold, so in our experience providers commonly treat any change touching a restricted operation as significant by default.

Does the pre-release code scan need to run on every deployment, or only major releases?

Every release. The policy covers new code, features or products released, not just major versions, so a small hotfix falls under the same obligation as a full release. Most teams we work with wire the scan into the CI/CD pipeline as a gate, so it runs regardless of how the release is labelled.

Is the seven-day fix deadline for critical findings different from the deadline for high-risk ones?

Yes. Critical-risk vulnerabilities carry a seven-day deadline from the date of discovery; high-risk ones carry 30 days. Both apply regardless of which obligation surfaced the finding, the 30-day scan, the code scan or the annual test, and both are counted from discovery, not report delivery.

What does running the full Amazon SP-API vulnerability management programme cost across a year?

Most of the annual cost sits in the penetration test itself: typically 5 to 6 days at £1,100 to £1,400 a day, so £5,500 to £8,400, rising to £8,800 to £12,600 with the cloud environment included. The 30-day scanning and code scanning run on automated tooling and add little on top.

Can one annual penetration test satisfy both Amazon’s requirement and a buyer’s own security questionnaire?

Usually, yes, if scoped for both from the outset. A report covering the DPP’s asset categories, with a clear scope statement, severity-mapped findings and a validation retest, gives you a signed independent attestation suitable for third-party security review, alongside the evidence Amazon’s compliance check asks for.

Get your Amazon SP-API vulnerability management programme scoped

If your SP-API application performs a restricted PII operation, tell us which parts of the scan, test and remediation cadence are already in place. Get a CREST pentesting quote and we will scope the rest of the programme around what’s missing.

Related research

For whether the policy applies to your application at all, see does Amazon SP-API require a penetration test. For which operations count as restricted, see restricted SP-API operations and PII. For the wider ecommerce picture, see our ecommerce penetration testing guide.