Amazon’s Data Protection Policy is usually discussed as a penetration testing requirement. That is clause 2.7.2, it fires once every 365 days, and we cover it in detail in what the DPP requires of a pentest.
This page is about the clause immediately above it. Clause 2.7.1 fires twelve times a year at minimum, plus once per release, plus every time you make a significant change. It is the obligation most Solution Providers are quietly failing, because it is the one nobody sells them.
Key findings
- 2.7.1 is three sentences and three separate obligations, not one scanning contract: scanning at least every 30 days, change-triggered scanning after significant network, application or infrastructure changes, and code scanning before each software release.
- The change-triggered leg has no calendar attached. Almost every scanning product on the market does the reverse of what it asks: it runs on a schedule and reports what changed since last time. That is change detection, not change-triggered scanning.
- Clause 2.7’s preamble sets the scope, and it is wider than most scoping documents assume: all information systems, applications and infrastructure components that store, process or transmit Amazon data, including PII.
- The policy is methodology-neutral; Amazon’s guidance is not. Clause 2.7.2 requires an “industry-recognized methodology” without naming one, and the key security controls guidance names no framework. But the vulnerability management guidance states that scanning tools “must follow the standards given by OWASP”, reproduces the OWASP Top 10 for 2025 with CWE mappings, and links OWASP ZAP. Read both before writing either into a compliance document.
- The remediation clocks in 2.7.3 apply to scan findings too, not just pentest findings: critical in 7 days from discovery, high-risk in 30.
- The common failure is evidence, not scanning. Twelve unindexed PDFs are not a demonstrated 30 day practice.
What clause 2.7.1 actually says
The preamble to clause 2.7 sets the scope for everything under it:
“Solution Provider must create and maintain a documented vulnerability management plan and/or runbook to detect and remediate vulnerabilities. Solution Provider must ensure vulnerabilities are detected and remediated across all information systems, applications, and infrastructure components that store, process, or transmit Amazon data, including PII.”
Then 2.7.1 itself:
“Vulnerability scanning conducted at least every 30 days. Change-triggered vulnerability scanning required following significant network, application or infrastructure changes. Code scanning for vulnerabilities completed prior to each software release.”
Read those two quotes together and the shape of the obligation is clear. It is not “run a scanner monthly”. It is a documented plan, applied to every system in your Amazon data path, executed on three different triggers.
Amazon restructured clause 2.7 on 25 November 2025. If your last compliance review predates that, the version you worked from reads differently. The restructure split 2.7 into four numbered sub-clauses and added requirements that did not exist before, including a 12 month log retention minimum, an 18 month cap on non-PII retention and mandatory third-party risk assessments for subcontractors.
Obligation one: scanning at least every 30 days
The frequency is the easy part. The scope is where this goes wrong.
The preamble says every system that stores, processes or transmits Amazon data. For a typical SP-API integration that is wider than the public website:
- The application that calls SP-API, and its backend
- Any datastore holding Amazon data, including caches and queues
- The hosting environment and its network boundaries
- Anything that processes PII after it arrives, including internal tooling
Amazon’s key security controls guidance says the same thing in plainer words: “Conduct vulnerability scanning at least every 30 days across all systems that process or store Amazon data.”
One scoping trap from section 2 itself is worth carrying into this: if PII is combined with non-PII in the same data store, Amazon states the entire data store must comply with the section 2 requirements. A shared database pulls more into scope than teams expect.
Obligation two: change-triggered scanning
This is the leg almost nobody meets, and the reason is structural rather than lazy.
What most tools do: run on a schedule, diff against the previous run, report new findings. A new subdomain, a newly opened port, a fresh certificate, a changed DNS record or a misconfigured bucket is noticed at the next scheduled scan, which can be up to 30 days later.
What 2.7.1 asks for: the change causes the scan.
Amazon does not define “significant”, which means you define it and defend it. A definition that holds up looks like this:
- Any change to internet-facing infrastructure, including DNS, certificates, load balancers and firewall rules
- Any change to an authentication or authorisation path
- Any change to a system that stores, processes or transmits Amazon data
- Any new environment, region or third-party integration in that path
Write it into the vulnerability management plan the 2.7 preamble already requires. A plan with a stated definition is defensible even if an assessor would have drawn the line differently. A plan with no definition is the gap they will find.
The practical implementation is less work than it sounds, because the trigger events already exist in your pipeline: an infrastructure-as-code apply, a merge to main, a production release. The scan does not have to be exhaustive on every trigger. A targeted scan of what changed, recorded and dated, demonstrates the practice.
Obligation three: code scanning before each release
The third sentence is the most specific of the three: code scanning for vulnerabilities completed prior to each software release.
Amazon’s guidance names the tool classes rather than products: SAST, DAST and IAST. It separately points at Amazon Inspector for workload and network exposure scanning.
Two things follow. First, this is a pipeline control, not a periodic activity, so it belongs in CI rather than on a calendar. Second, “prior to each release” means a failing scan has to be able to stop a release, or the control is documentation rather than practice.
What an external scan reaches, and what it cannot
This section exists because the honest answer is commercially inconvenient for anyone selling external scanning, including us.
An external, unauthenticated scan reaches:
| Layer | What it sees |
|---|---|
| DNS and domains | Records, subdomains, certificate transparency, email authentication posture |
| Transport | TLS versions and cipher configuration on public endpoints |
| Network | Open ports and the services behind them |
| Web | Exposed panels, served JavaScript, known CVEs on public-facing software |
It cannot reach, in principle and not merely by configuration:
- A database inside a private network
- An admin console behind single sign-on
- A queue worker, a CI runner, an internal API
- An employee endpoint
- An application release that changes business logic without altering anything externally observable
That last one is worth sitting with. A deploy that rewrites an authorisation check behind an unchanged URL produces an identical external scan. The scan is not wrong. It is looking at the outside of a building whose interior was rearranged.
So an external scan is a component of 2.7.1, not a discharge of it. For most Solution Providers the external surface is the layer that changes without anyone deciding to change it, which is exactly why it deserves a standing cadence. It is also, on its own, a subset of the scope the preamble sets.
The evidence, which is where this usually fails
Section 3 of the policy requires you to maintain records reasonably required to verify compliance during the agreement and for 12 months afterwards, and to certify compliance in writing on Amazon’s written request.
For scanning, the file that survives a request looks like this:
- Cadence stated. What the configured interval is, not just that scans happened.
- Scope stated per scan. What was enumerated, so the reader knows what the finding count is a count of.
- Tool inventory per scan. What ran, so a reader can judge coverage.
- Findings with disposition, mapped to the 2.7.3 clocks: fixed, accepted with reasoning, or open with a date.
- A history index. The series, in one place.
We have seen the failure mode often enough to name it: the scans were genuinely run, and the evidence is twelve unrelated PDFs with no index, no cadence statement and no scope description. The count is treated as the proof. An assessor asking for twelve months of 30 day scanning wants a series, not a pile, and reconstructing eleven months of history after the request arrives is where the time goes.
Amazon’s own tooling, and its limits
Amazon points at five tools by name across its security guidance. Two are free.
| Tool | Free? | What Amazon says it does |
|---|---|---|
| SP-API Guard | Yes, first-party | Serverless application scanning AWS data against the DPP, findings report after 24 hours |
| OWASP ZAP | Yes, open source | Amazon links its penetration test guide directly |
| OWASP scanning tools list | Free directory | Amazon links OWASP’s own list of free and paid scanners |
| Amazon Inspector | No, billed AWS service | ”a scalable vulnerability management tool which scans workloads and unintended network exposures” |
| AWS Resilience Hub | No, billed AWS service | Named for establishing the RTO and RPO targets clause 2.7.4 requires |
Nothing on that list performs the 2.7.2 penetration test. Amazon describes that separately as a five stage exercise with a human tester attempting to gain access.
SP-API Guard is free and first-party. Amazon describes it as a serverless application that scans AWS data to assess security compliance with the Data Protection Policy, using custom scan rules built with AWS Security services, returning a findings report with remediation recommendations after 24 hours.
Run it. Then note two limits before planning around it:
- It is documented against AWS only. A Solution Provider on another cloud, on bare metal or in a hybrid estate gets nothing from it.
- It assesses configuration against policy requirements. It is not probing your application’s authentication, authorisation or business logic.
Amazon’s own vulnerability management guidance lists Guard and Amazon Inspector under tooling, and describes penetration testing separately as a five stage exercise with a human tester. That separation is Amazon’s, not ours.
The clocks, together
Three obligations on three triggers, and a fourth clock underneath all of them:
| Clause | Obligation | Trigger |
|---|---|---|
| 2.7.1 | Vulnerability scanning | At least every 30 days |
| 2.7.1 | Change-triggered scanning | A significant change |
| 2.7.1 | Code scanning | Prior to each release |
| 2.7.2 | Penetration test | At least every 365 days |
| 2.7.3 | Remediation | Critical 7 days, high-risk 30 days, from discovery |
The remediation clocks are the ones that bite, because they run from discovery rather than from triage. A scan you do not read is a clock you have already started. Plan the cadence against the remediation capacity you actually have. A documented record of missed 7 day deadlines is worse evidence than a slower cadence you can meet.
Where we fit, and where we do not
We run a free monthly external attack surface scan. It is external and unauthenticated, it covers the layer described in the table above, and it reports on a 30 day cadence. It is a component of 2.7.1’s first sentence for the external surface, and we would rather write that sentence precisely than sell it as compliance. It does not reach your private network, it does not scan your code, and it is not triggered by your deploys.
For clause 2.7.2, the annual penetration test, that is a separate engagement. The scope, the price and the business days are set out on our Amazon SP-API DPP penetration testing page, with the underlying plans on our pricing page.
What we will not tell you is that any of it makes Amazon approve your application. Amazon reviews your developer profile and your compliance position, and no testing vendor can approve it on Amazon’s behalf. What a vendor can do is follow the published requirements and give you evidence that is legible to the person reviewing it.
Corrections and updates
We publish corrections rather than editing them away, so a reader who acted on an earlier version can see what changed. Some entries record a change in the source document itself, others record our own error. Dates are our review dates, not the source's change date.
Errors in this page are corrected in place with a dated note. If you believe something here misreads the policy, tell us and we will check it against the source and publish the outcome either way. Our corrections policy sets out how.
Sources, all accessed 30 September 2026: Amazon Data Protection Policy clause 2.7, revision effective 25 November 2025, at sellercentral.amazon.com; developer-docs.amazon.com/sp-api/docs/guidance-to-address-key-security-controls-in-sp-api-integration; developer-docs.amazon.com/sp-api/docs/vulnerability-management; developer-docs.amazon.com/sp-api/docs/sp-api-guard-implementation-guide; developer-docs.amazon.com/sp-api/docs/security-compliance-overview; and the DPP and AUP changelog entry effective 25 November 2025.