AWS Marketplace SaaS Security Requirements

AWS Marketplace’s SaaS security requirements are the ten security policies AWS added to its SaaS product guidelines on April 30, 2026, from a six-topic data-handling disclosure to audit logs kept for at least a year. AWS says it reviews products against its guidelines continuously, so the policies reach listings that are already public. This guide quotes each one and sets it beside the evidence to keep.

---

Acme has sold its analytics product through AWS Marketplace since 2025. At an October planning meeting, its CTO asks the security lead two questions about the section AWS added to its SaaS guidelines in April: does it apply to a listing that’s already public, and could Acme show that it meets every line?

The first answer is yes; the second is a worksheet. Much of AWS’s list will be familiar from buyers’ security questionnaires. What’s new is who is asking. Our checklist of cloud marketplace listing requirements says that enterprise buyers, rather than the marketplace, set the security bar. Buyers still set the higher bar, but for SaaS products on AWS there is now a written floor beneath it, and AWS says it keeps reviewing products against its guidelines after submission.

Each policy below is quoted in AWS’s words, then set beside the evidence we’d keep, the owner we’d give it, and where a buyer would see it. Those three are our suggestion, not AWS’s, and none of this is legal or compliance advice.

What are AWS Marketplace’s SaaS security requirements?

AWS Marketplace’s SaaS security requirements are the ten policies in the “Security policies” section of AWS’s SaaS product guidelines. The section opens: “All SaaS products must comply with the following security policies.” AWS’s Seller Guide document history dates the section April 30, 2026, and says it “outlines security requirements including data protection, vulnerability management, and incident response.”

In brief, AWS requires:

1. Compliance with the local laws and regulations that apply to your company and your customers, “such as” GDPR and CCPA
2. No known vulnerabilities, end-of-life software, malware or other malicious code at publishing, and patches for issues found afterwards
3. A disclosure of your data-handling practices that covers six topics
4. Deletion of customer data when it’s no longer necessary as your EULA defines it, or on request, within the EULA’s timeframe
5. Industry-standard encryption of customer data in transit and at rest
6. Isolation of each customer’s data and environment from every other customer, unless the customer explicitly permits access
7. Authentication of every customer before access to customer data
8. Notice to impacted customers of any security incident that could be relevant to them
9. A documented process for customers to report a security incident
10. Audit logging of security-relevant events, kept for at least a year and protected from tampering

Two details are easy to misread. April 30, 2026 is the date AWS added the section to its documentation: the section states no effective date of its own, unlike the architecture guidelines further down the page, which are “effective as of May 1, 2025.” And the section closes with a recommendation, not an eleventh rule: “For a more comprehensive review of your security posture, use the AWS Well-Architected Framework.” The rest of the page covers product setup, customer information, product usage and architecture; this guide covers the security section.

Do AWS’s security policies apply to listings that are already live?

Yes. The section applies to “All SaaS products,” with no exception for products published before April 30, 2026, and AWS says it reviews published products against its guidelines continuously. The guidelines open with AWS’s terms:

“All products and their related metadata are reviewed when submitted to ensure that they meet or exceed current AWS Marketplace guidelines. These guidelines are reviewed and adjusted to meet our evolving security requirements. In addition, AWS Marketplace continuously reviews products to verify that they meet any changes to these guidelines. If products fall out of compliance, we might require that you update your product and in some cases your product might temporarily be unavailable to new subscribers until issues are resolved.”

Three things to take from that paragraph:

• It covers all of the SaaS guidelines. It introduces the whole page, from product setup to architecture, not the security section alone. The security policies are simply the newest rules it applies to.
• AWS names two possible consequences: it might require an update, and in some cases a product might be temporarily unavailable to new subscribers, the buyers your pipeline is waiting on.
• AWS doesn’t say how it reviews each policy, or what evidence it might ask for. Having the evidence ready is the part you control.

The vulnerability policy makes the same point in its own words: a product must be clean “at the time of publishing,” and “If security issues or vulnerabilities are detected post-publication, the seller must patch them.”

If your SaaS product deploys an AMI or a container into the buyer’s AWS account, that component also has to meet AWS’s AMI-based or container-based product requirements, as a separate add-on product that AWS Marketplace scans “for unpatched common vulnerabilities and exposures (CVEs) and security requirements.” How security reviews shape marketplace deals quotes AWS’s AMI policies, and covers the review a buyer runs on top of AWS’s.

How do you turn AWS’s security policies into a compliance worksheet?

Give each policy one row: AWS’s words, the evidence that shows you meet it, a named owner, and the place a buyer sees it. Only the first column is AWS’s. The evidence, owner and buyer-facing columns are our suggestion: AWS’s guidelines don’t say what evidence it reviews or who should own a policy, and apart from the data-handling disclosure, they don’t say where a buyer should find the answer.

AWS’s policy, quoted	Evidence to keep (our suggestion)	Owner (our suggestion)	Where a buyer sees it (our suggestion)
“Product must comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as the General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), and others.”	A register of the laws that apply to you and your customers, each with the date counsel last reviewed it	Legal	Privacy notice; data processing terms
”Product must be free of known vulnerabilities, end-of-life software, malware, and other malicious code at the time of publishing. If security issues or vulnerabilities are detected post-publication, the seller must patch them.”	Scan results from before each release, a dependency inventory with end-of-life dates, and patch records from detection to fix	Engineering	Security page; release notes
”Seller must disclose their data handling practices to customers through customer-facing documentation or by request.”	The disclosure itself, versioned and dated, answering all six topics (template below)	Security, with legal	Customer-facing documentation, or on request: AWS’s own two routes
”Seller must delete customer data when it is no longer necessary as defined in the End User License Agreement (EULA), or upon customer request. Deletion must occur within the timeframe specified in the EULA.”	The EULA clause that sets the timeframe, a deletion runbook that covers backups, and a dated log of completed requests	Legal for the clause; engineering for the deletion	EULA
”Product must use industry-standard means of encryption to protect customer data in transit, and at rest.”	TLS configuration for every endpoint, and encryption settings for every data store and backup	Engineering	Security documentation; the disclosure’s storage line
”Product must isolate each customer’s data and environment so that no other customer can access them, unless the customer explicitly permits access.”	The tenancy design, tests that attempt cross-customer access, and a record of each access a customer permitted	Engineering	Architecture or security documentation
”Product must authenticate all customers before granting access to customer data.”	The authentication design, including the path a marketplace buyer takes from sign-up to first sign-in, and tests that unauthenticated requests are refused	Engineering	Sign-in and onboarding documentation
”Seller must notify impacted customers about any security incident that could be relevant to them.”	An incident response plan with a customer-notice step, current security contacts for each customer, and records of notices sent	Security	Incident policy; any notice window your EULA sets
”Product must have a documented process for customers to report a security incident related to the product.”	The published reporting route, and a periodic test that a report reaches whoever is on call	Security	Security page; support documentation
”Seller must enable audit logging of security-relevant events when the product processes customer data. Audit logs must be retained for at least 1 year and must be protected from tampering.”	The list of events logged, retention settings of a year or more on every log store, and the control that prevents changes	Engineering, with security	Security documentation; the disclosure’s retention line

Two rows need legal and engineering in the same room:

• Deletion runs on the EULA’s clock. The timeframe legal writes is the one engineering must meet, backups included. Check that the agreement your listing declares, whether your own EULA or AWS’s standard contract, states a timeframe your team can actually meet.
• Incident handling runs in two directions. AWS asks you to notify impacted customers, and to give customers a documented way to report an incident to you. A plan that covers only the first leaves the ninth row empty.

What must the data-handling disclosure cover?

Six topics: data collection, storage, usage, sharing, retention and backup. AWS requires sellers to “disclose their data handling practices to customers through customer-facing documentation or by request,” so either a published page or a document you send when asked fits AWS’s wording. We’d publish it, because the same questions arrive in buyers’ security reviews anyway.

The topics are AWS’s. What to state under each is our suggestion.

Topic (AWS’s list)	What to state (our suggestion)
Data collection	What you collect from customers and their users, such as account details, content they upload, and usage and log data, and how you collect it
Data storage	Where customer data is stored, by provider and region, and how it’s encrypted at rest
Data usage	What each kind of data is used for, and what it’s never used for
Data sharing	Every party that receives customer data on your behalf, such as subprocessors, support tools and marketplace tooling, and why
Data retention	How long each kind of data is kept, what ends that period, and the deletion timeframe your EULA sets
Data backup	How often backups run, how long they’re kept, and whether the deletion timeframe reaches them

Write the retention line last, because three things meet in it: AWS’s deletion rule, AWS’s one-year audit-log rule, and backups, which hold deleted data until they expire. AWS’s page doesn’t say how those interact, so your disclosure is where you say it. An illustrative line for Acme, whose numbers are Acme’s choices rather than AWS’s:

When your subscription ends, or when you ask, Acme deletes your data within 30 days, the period our EULA sets, and the backups that hold it expire within the same 30 days. Security audit logs record account activity, not your datasets, and are kept for 13 months, then deleted.

How long must audit logs be kept for an AWS Marketplace SaaS product?

At least one year, protected from tampering. AWS’s policy reads: “Seller must enable audit logging of security-relevant events when the product processes customer data. Audit logs must be retained for at least 1 year and must be protected from tampering.”

AWS doesn’t say which events count or how to protect the logs, so the specifics below are our suggestion:

• Which events. Start with sign-ins and failed sign-ins; changes to users, roles and permissions; API keys and tokens created or revoked; changes to security settings such as SSO and MFA; data exports and bulk downloads; deletion requests and their completion; and every time your own staff access a customer’s environment.
• A full year, everywhere. Logs often pass through more than one store, such as the application’s log store, a SIEM and an archive, and the shortest retention among them is your real figure. Keep the retention settings themselves as evidence.
• Tamper protection. Write logs once, to storage that the application’s own credentials can’t alter or delete, and log access to the logs. A per-file digest or a similar integrity check lets you show that a log hasn’t changed since it was written.

What does Fours handle, and what stays with your team?

Fours creates and submits your AWS Marketplace listing and hosts the sign-up redirect. The ten policies apply to your product and your company, so they stay with your team. Fours can’t meet any of them for you. What it touches is where a buyer meets your answers.

• The listing. You fill in the listing in the Fours Console and Fours creates it on AWS Marketplace. Three of its fields carry parts of the worksheet to a buyer evaluating it: the EULA, either AWS’s standard contract or your own uploaded as a PDF, which is the agreement AWS’s deletion rule points to; up to three Resources, shown under “Additional Support” on the listing, one of which could link your security documentation or data-handling disclosure; and the required Support Details, your support email, hours and expected response time. The guide to building and testing an AWS Marketplace listing in Fours covers each field.
• Sign-up. A buyer who subscribes reaches Fours through the fulfillment URL. Fours registers the entitlement and the buyer’s details, then redirects the buyer to your sign-up page with an entitlement ID your application stores with the account, or to a sign-up form Fours hosts. Authenticating the customer and isolating their data happen in your application, after that handoff. Buyer details pass through Fours on the way, so we’d name it with your other service providers in the disclosure’s sharing line.
• Submission. When the listing is ready, Publish Product sends AWS the request to make it public. From there, the review is in AWS’s hands.

None of that changes what AWS asks of your product. Encryption, isolation, authentication, deletion, incident handling and audit logs are your engineering and security teams’ work, and the worksheet is how you show it’s done.

Frequently asked questions

When did AWS add security policies to its SaaS product guidelines?

On April 30, 2026. AWS’s Seller Guide document history lists “Added security policies for SaaS products” on that date: a new section of security requirements, including data protection, vulnerability management and incident response. The section states no separate effective date.

Do AWS’s SaaS security policies apply to existing listings?

Yes. They apply to “All SaaS products,” and AWS says it “continuously reviews products to verify that they meet any changes to these guidelines.” If a product falls out of compliance, AWS might require an update, and in some cases it might be temporarily unavailable to new subscribers.

How long must audit logs be kept for an AWS Marketplace SaaS product?

At least one year. When a SaaS product processes customer data, AWS requires audit logging of security-relevant events, with logs “retained for at least 1 year” and “protected from tampering.” AWS doesn’t list which events count, so define the set yourself.

What must a SaaS data-handling disclosure cover on AWS Marketplace?

Six topics: data collection, data storage, data usage, data sharing, data retention and data backup. AWS lets you make the disclosure through customer-facing documentation or by request.

Does Fours meet AWS’s security policies for you?

No. Fours creates and submits your AWS Marketplace listing and hosts the sign-up redirect, but the policies apply to your product and your company. Encryption, isolation, authentication, deletion, incident handling and audit logs stay with your team.

Is GDPR or CCPA compliance required to sell SaaS on AWS Marketplace?

AWS requires SaaS products to comply with the local laws and regulations that apply to your company and your customers, and names GDPR and CCPA as examples. Which laws apply to you is a question for your counsel.

Takeaways

• Since April 30, 2026, AWS’s SaaS product guidelines carry ten security policies, and AWS says it reviews products against its guidelines continuously, so a listing that’s already public is in scope.
• Keep one worksheet row per policy, with evidence, an owner and a place a buyer sees it, and make the EULA’s deletion timeframe, your backup schedule and the one-year audit-log rule agree.
• Fours creates and submits the listing and hosts the sign-up redirect; meeting the ten policies is your team’s work.

The policies are yours to meet, and the listing is the part Fours can take on. See how Fours’ marketplace listing automation creates and submits listings for six marketplaces, so your team’s time goes to the worksheet.