Your Amazon SP-API app just got homework. On Nov 11, 2025, Amazon updated its Data Protection Policy (DPP) and Acceptable Use Policy (AUP). Keep using the API after Nov 25, 2025, and you’ve accepted the updates. Translation: if your security, data flows, or terms are still 2024, you’re out of date.
Here’s the kicker—this isn’t a simple checkbox. Amazon is tightening how you handle PII, who sees what, and what your app can do with marketplace data. If you build or buy software touching seller or buyer data, you need to align fast.
Good news though. This playbook explains what changed, what to fix, and how to pass an audit without wrecking your roadmap. You’ll leave with a plan to run this week, a clean story for stakeholders, and fewer reasons to panic when Amazon asks for proof.
One more thing: Amazon can ask you to show your work, not just promise you’re “secure.” Think screenshots, policies, architecture diagrams, access reviews, and logs on demand. If your stomach just dropped, you’re not alone. With a tight plan and a few templates, you can hit compliance and keep shipping.
TLDR
- Amazon updated SP-API DPP and AUP on Nov 11, 2025; use after Nov 25, 2025 means acceptance.
- Expect stricter controls for PII, narrower allowed uses, and clearer accountability.
- You’ll likely update encryption, access controls, logging, and data-retention practices.
- Refresh privacy notices, DPAs, and client agreements to reflect new terms.
- Use Amazon’s tooling (e.g., developer docs) and prep for ongoing compliance checks.
What Changed and You
Effective dates and acceptance
- Amazon published updates to the SP-API Data Protection Policy and Acceptable Use Policy on November 11, 2025. Continued use of Amazon Services API after November 25, 2025 constitutes acceptance of the updated agreements. If you’re shipping updates on a sprint cycle, that’s one sprint to align.
Consider this your stopwatch moment. If your release cycle runs two weeks, thread compliance tasks into your next sprint. Make them acceptance criteria. Tie user stories to controls like encryption at rest, least-privilege roles, and purge jobs. Ship the feature and the control together.
Whats inside the update
- Stronger PII handling: tighter encryption in transit and at rest, stricter key management, and expectations for least-privilege access.
- Usage boundaries: clearer allowed versus prohibited API use, especially around repurposing, scraping-like behaviors, and third-party sharing.
- Accountability: more emphasis on auditing, breach reporting, and proving compliance on demand.
In practice, this means you should review:
- Where you store tokens and PII, how you rotate keys, and who can access logs.
- Your feature set vs. allowed use—if you aggregate or enrich data beyond a seller’s intent, re-check the AUP.
- Vendor chain: do your subprocessors meet the same controls? If not, fix it or swap them.
Here’s how to turn that into action this week:
- Map every touchpoint for SP-API data: ingest, transform, store, backup, export, logs, and analytics. Mark what’s PII.
- Compare your app’s purposes to what sellers consented to in OAuth and your privacy notice. If you do extra, stop or get consent.
- For vendors, request their SOC 2 report, ISO 27001 cert, or equivalent. Verify encryption, access controls, and incident response. No proof, no PII.
Why this matters now
Amazon’s SP-API replaced MWS to modernize security and granularity. These 2025 updates keep tightening the rules. The goal is simple: protect buyers and sellers while keeping the ecosystem useful. Align now and you’ll move faster later. Fewer audit findings, fewer prod surprises, and more trust with customers who care about compliance.
Think of it like seatbelts for your app. Slight effort up front. Massive upside when things go wrong. Enterprise customers expect this. If you can say “we follow Amazon’s DPP, our AUP matches theirs, and here’s evidence,” you’re not just compliant—you’re credible.
Lock Down Data Controls
Protect PII like its money
- Encrypt in transit (TLS 1.2+) and at rest with strong customer-managed keys where feasible.
- Stop storing more than you need. Minimize fields, redact payloads in logs, and enforce retention windows.
- Segregate environments. If production PII lands in dev, that’s a compliance problem, not a test dataset.
“Security is a process, not a product.” — Bruce Schneier. Translation: make controls repeatable. Document them. Test them. Improve them.
Make this real with simple moves:
- For logs, add redaction middleware that strips emails, names, and full addresses before events hit your sink. Keep IDs, timestamps, and error codes.
- Use key rotation policies and track last-rotated dates in a dashboard. Automate rotation where your platform supports it.
- Create scrubbed datasets for dev and QA: synthetic data, reversible tokenization for support, or field-level masking. No “just this once” prod exports.
- Implement deletion SLAs. When access is revoked, start a timed purge job and record completion. Evidence matters.
Access and authentication zero trust
- Least privilege across the board: scoped roles, short-lived credentials, and policy-based access.
- MFA for human access, workload identities for services. Rotate keys often and automate revocation on offboarding.
- Block lateral movement: network segmentation, VPC endpoints for outbound calls, and guardrails on egress.
Add guardrails your future self will thank you for:
- Use role-based access control tied to job functions. Support can view metadata, not full payloads. Developers can view error traces, not PII.
- Prefer OAuth/OIDC and short-lived tokens with scopes matching the exact SP-API operations you use. No blanket permissions.
- Enforce SSO + MFA for the admin console. Disable local accounts. Automate offboarding with your IdP so access is revoked within minutes.
- Egress filtering: only allow outbound traffic to known SP-API endpoints and your dependencies. If malware lands, it can’t phone home.
Logging auditing and incident response
- Centralize logs (API calls, auth events, data exports) into a SIEM. Alert on anomalies like sudden spikes, unauthorized scopes, and off-hours pulls.
- Prove it exists: retain audit logs per policy, and be able to export evidence quickly.
- Drill incident response: define RACI, run tabletops, and test breach notifications. If you can’t simulate a compromise and recover, you’re not ready.
Need an audit-ready way to query logs and export evidence on demand? Explore Requery.
Pro tip: Map controls to NIST SP 800-53 categories (AC, AU, CM, IR) and OWASP ASVS for app-layer rigor. That turns “we’re secure” into “we meet recognized standards.”
Practical playbook:
- SIEM alerts to set now: excessive 4xx from auth endpoints, a token requesting new scopes, data export jobs outside a maintenance window, and IPs outside allowed geos.
- Audit prep: save monthly exports of access reviews, key-rotation logs, and incident tabletop notes in a read-only repository. Tag with dates and owners.
- Incident drill starter: “A support laptop is lost; cached admin session may be active.” Walk through detection, containment, revocation, comms, and root cause.
Acceptable Use Examples
Acceptable use policy example context
Your AUP should echo Amazon’s. Spell out how users may and may not use data, what’s monitored, and consequences. A simple acceptable use policy example includes:
- Clear definition of permitted purposes tied to the service.
- Prohibitions on scraping, data resale, profiling unrelated to seller needs, and bypassing rate limits.
- Rights to suspend accounts, throttle, or revoke access when abuse is detected.
Make it crystal clear in your AUP:
- “You may use marketplace data only to operate your store management features (inventory, pricing, orders) and support services the seller asked for.”
- “You may not use buyer PII for advertising, cross-selling, or unrelated analytics.”
- “We monitor usage for security and reliability, including rate limits and anomaly detection. Abuse leads to throttling or termination.”
Read the fine print
- Repurposing PII for unrelated analytics or advertising.
- Combining marketplace data with third-party datasets to build profiles beyond what sellers consented to.
- Sharing raw SP-API data with vendors lacking equivalent protections.
- Automations that mimic scraping or bypass rate limits.
If you’re thinking “the AUP will spell out the company’s rights to” suspend, terminate, rate-limit, monitor, and log for security—yep, that’s the point. Mirror those rights in your own AUP.
Scenario check:
- You export order data to a BI tool for customer reporting. Fine—if it’s within purpose and protected.
- You feed buyer emails into a generic email ad platform. Not fine—outside purpose and likely violates Amazon’s rules and expectations.
- You enrich SP-API data with a data broker to score buyers. Extra not fine.
Rate limits automation and use
- Build for burst control: exponential backoff, queueing, and idempotent retries.
- Monitor call patterns. If an automated job hammers endpoints at 100x baseline off-hours, investigate.
- Consent-first sharing: if a seller disconnects your app, shut off data flows and purge per policy.
Helpful patterns:
- Use a work queue with retry policies and jitter. Respect per-endpoint throttles published by Amazon.
- Add idempotency keys to write operations so retries don’t double-post.
- Maintain a “consent ledger” that services check before processing. If the app is disconnected, the job stops—no exceptions.
An AUP helps employees by spelling out risks, monitoring, and penalties. Clarity isn’t scary; it keeps good users safe and bad behavior out.
Operational Cleanup Contracts SPP
Update your legal stack
- Privacy notices: disclose what you collect, how long you keep it, and how sellers revoke access.
- DPAs and client agreements: reflect the updated DPP/AUP, incident timelines, and your subprocessors list.
- Internal AUP: align team behavior with your external promises. No side-channel pulls. No “debug dumps” of live PII in Slack.
Quick wins:
- Run a policy diff between your docs and Amazon’s latest DPP/AUP. Highlight gaps like retention, data use, and third-party sharing. Fix them.
- Add a data-deletion commitment with a specific timeframe once access is revoked, and a way for customers to request deletion.
- Keep a public subprocessor page. When you add a vendor, update it and notify customers as your contract requires.
Program governance and portals
- Use Amazon’s developer documentation as your source of truth. Watch announcements and policy pages for changes and deadlines.
- Centralize partner management. Ensure every integration partner and subcontractor meets the same controls you do. Audit them.
Operationalize it:
- Assign an owner for SP-API compliance. This person tracks policy updates, coordinates fixes, and keeps evidence ready.
- Build a policy update checklist: review docs, run impact analysis, update AUP/privacy/DPA, run regression tests, notify stakeholders.
- Keep architecture diagrams current: data stores, queues, vendors, and encryption boundaries. Auditors love diagrams. Engineers do too.
Plan the next 12 months
- Budget for continuous compliance work: control testing, pen tests, and security training.
- Anticipate evolving platform economics and policy governance in 2026. Watch Amazon’s announcements for pricing or access changes that could hit your model.
- Build evidence on demand: dashboards for access reviews, key rotation, log retention, and incident drills.
Simple cadence that works:
- Monthly: access reviews for admin roles and tokens; scan for secrets in repos; review failed auth patterns.
- Quarterly: tabletop exercise; key rotation; vendor attestations; privacy notice review; AUP alignment check.
- Annually: third-party pen test; scope review for least privilege; data-retention audit; business continuity test.
When stakeholders ask “are we compliant?”, show artifacts. Policies, diagrams, control mappings, and last quarter’s audit log exports. Confidence beats vibes.
Speed Round Fix Before Release
- Map every data flow touching SP-API—including logs and backups—and label PII.
- Encrypt at rest and in transit; rotate keys; kill plaintext tokens.
- Narrow scopes and permissions; timebox access; enforce MFA.
- Centralize logs; alert on anomalies; rehearse incidents.
- Align your AUP, privacy notices, and client agreements to Amazon’s latest terms.
- Audit vendors and subprocessors; require equivalent controls.
If you have 2 hours:
- Disable any long-lived credentials and rotate keys used by CI/CD.
- Turn on MFA for all admin accounts; remove unused users.
- Add redaction to request logs.
If you have 1 day:
- Build a data map and mark PII fields; block PII from dev environments.
- Review scopes; drop permissions your app doesn’t need.
- Draft updates to your AUP and privacy notice for legal review.
If you have 1 week:
- Centralize logs to a SIEM and add alerts for anomalies.
- Run an internal mini-audit and track gaps with owners and deadlines.
- Execute a vendor control check and get proofs on file.
FAQ
What changed Amazon November 2025
Amazon tightened PII handling, clarified acceptable versus prohibited SP-API data use, and emphasized accountability. That means auditing, incident response, and proof on demand. Continued use after November 25, 2025 means acceptance. Update controls, docs, and contracts now.
Still on legacy MWS
MWS is deprecated in favor of SP-API. If you touch Amazon marketplace data, plan for SP-API alignment and policy compliance. Migrating to SP-API isn’t optional if you want long-term access.
Acceptable use policy example AUP
Include permitted purposes, prohibited behaviors like scraping and resale, and monitoring and logging practices. Add user responsibilities, your rights to throttle, suspend, or terminate, plus complaint handling, appeals, and data deletion on disconnect.
AUP meaning finance and audit
In IT and compliance, AUP means Acceptable Use Policy. In finance and audit, AUP means Agreed-Upon Procedures. That’s limited-scope procedures with findings but no opinion. Different contexts, same acronym. Spell it out to avoid confusion.
AUP will usually warn users
A solid AUP warns about prohibited activities, monitoring, rate limits, data duties, and consequences. It won’t promise unlimited retention, unrestricted sharing, or immunity from enforcement. If you see that, big red flag.
AUP will spell out rights
To monitor usage for security, collect and retain logs per policy, and enforce rate limits. Also to suspend or terminate access and require remediation. It may reserve the right to update terms with notice.
Need pen test or audit
They aren’t always explicitly required for SP-API access. But they’re strong proof you take security seriously. They also find real issues early. Bigger customers will ask for them.
Handle data subject requests
Keep it simple. Intake, route to your privacy lead, validate identity, find data in your map, and respond within your timeframe. Document what you did and when.
What counts as proof
Think screenshots, exported logs, policies with version history, architecture diagrams, access review reports, and tickets. Show key rotations and incident drills. Aim for traceability: policy -> control -> evidence.
Ship a Compliant Update
1) Inventory data flows: APIs, webhooks, logs, backups, and analytics.
- Output a diagram. Mark stores, queues, and vendors.
- Label PII fields (buyer name, address, phone, email) clearly.
2) Minimize and encrypt: drop unnecessary fields, encrypt at rest/in transit, rotate keys.
- Turn off collection you don’t use. Less data, less risk.
- Verify TLS settings and cipher suites. Enforce HTTPS everywhere.
3) Tighten auth: least privilege, short-lived tokens, MFA, offboarding automation.
- Reduce scopes to what your features need today.
- Kill shared accounts. Tie every action to a person or service identity.
4) Harden pipelines: secrets management, signed artifacts, and SBOMs for dependencies.
- Store secrets in a vault; never in code or CI variables in plaintext.
- Sign builds; verify before deploy. Track third-party libraries.
5) Centralize logging: correlate API calls, auth events, exports; set anomaly alerts.
- Define a baseline: normal calls per hour and export size.
- Alert when you blow past that baseline.
6) Update paperwork: AUP, privacy notices, DPAs, subprocessor list, run a policy diff.
- Align terms with your actual practices—no wishful thinking.
- Add a clear disconnect-and-delete commitment.
7) Prove it: run a mini-audit, fix gaps, and keep evidence ready for Amazon.
- Assign owners and dates to every gap.
- Store evidence in a read-only folder with version history.
You don’t need perfection—just disciplined, documented, and demonstrable control.
Here’s the bottom line: compliance isn’t a tax on innovation; it’s how you earn trust. Amazon’s November 2025 DPP and AUP push you to treat PII like a liability. Use data only for what users intended. Prove you’re doing the right thing, consistently. Make this a routine—quarterly checks, clear AUPs, tight scopes—and you’ll move faster, close bigger customers, and sleep at night. Start with the seven steps, lock in your AUP and data flows, and you’ll be ready for whatever Amazon ships next.
Looking for real-world examples of compliant Amazon integrations? Browse our Case Studies.
References