Key Takeaways
- Cloud hosting never changes the validation route. Merchant level and payment channel do; a Level 1 merchant needs a QSA-led ROC wherever the environment runs
- SAQ A eligibility is about fully outsourcing card data handling and confirming your site resists script attacks, not about who owns the servers
- Running your own payment application on cloud VMs or containers puts you in SAQ D, which covers every applicable requirement
- The provider's AOC reduces the controls you evidence, not the SAQ you complete or the level you sit at
Does Hosting in the Cloud Change Whether I Need an SAQ or a ROC?
No. PCI DSS has two validation instruments. A Report on Compliance (ROC) is a full assessment performed by a Qualified Security Assessor, or in some programmes an Internal Security Assessor, who examines evidence for every applicable requirement and signs an Attestation of Compliance. A Self-Assessment Questionnaire (SAQ) is completed and signed by the organisation itself, with the set of questions depending on how card data is accepted.
Which instrument you use is decided by two things: your level, which the card brands and your acquirer assign on annual transaction volume, and your payment channel, which decides the SAQ type if an SAQ is permitted. Neither of those inputs mentions hosting. Infrastructure outsourcing affects which controls you can inherit from a provider, not which route you are on. That distinction runs through the rest of this article.
Merchant and Service Provider Levels
Levels are defined by each card brand, and your acquirer tells you which one applies. The thresholds below are the commonly cited Visa and Mastercard figures. Confirm your own level with your acquirer, because brands count transactions differently and can assign a higher level to any merchant, for example after a breach.
| Level | Typical threshold (per brand, per year) | Validation |
|---|---|---|
| Merchant Level 1 | Over 6 million transactions, or designated Level 1 by the brand | ROC by a QSA (or ISA where the brand permits), plus AOC and quarterly ASV scans |
| Merchant Level 2 | 1 million to 6 million transactions | SAQ, plus quarterly ASV scans; some brands and acquirers require QSA or ISA involvement |
| Merchant Level 3 | 20,000 to 1 million e-commerce transactions | SAQ, plus quarterly ASV scans where applicable |
| Merchant Level 4 | Under 20,000 e-commerce transactions, or under 1 million across all channels | SAQ, as directed by the acquirer |
| Service Provider Level 1 | Over 300,000 transactions stored, processed or transmitted | ROC by a QSA, plus AOC and quarterly ASV scans |
| Service Provider Level 2 | Under 300,000 transactions | SAQ D for Service Providers, although customers often require a QSA-signed ROC |
Two notes on the table. Visa merged its merchant Levels 3 and 4 into a single Level 3 in 2024, so a Visa-assigned level may not match the Mastercard numbering. And the level applies to the organisation, not to a particular system: moving a workload to the cloud does not change how many transactions you process.
Which SAQ Fits Which Cloud Architecture?
PCI DSS v4.0.1 has nine SAQ types: A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC and D, with D split into a merchant and a service-provider version. The reduced-scope types each have eligibility criteria set by the PCI Security Standards Council, and you must meet every criterion to use one. The table maps the cloud architectures we see most often to the SAQ that normally applies.
| Cloud-hosted architecture | Usual route | Why |
|---|---|---|
| Website on cloud hosting that redirects to, or embeds an iframe from, a validated payment provider; no card data touches your systems | SAQ A | All cardholder data functions are outsourced and the whole site has been confirmed not susceptible to script attacks, as the v4.0.1 SAQ A criteria require |
| Website whose own page elements control how card data is captured before it goes to the provider (direct post, merchant-hosted form fields, JavaScript from your origin) | SAQ A-EP | Your web server can affect the security of the transaction, so it is in scope and A-EP adds the web-facing requirements |
| Your own payment application on cloud VMs, containers or serverless functions that receives or stores PANs | SAQ D for Merchants | You operate the cardholder data environment; every applicable requirement applies |
| Application that only ever handles tokens issued by a validated third party; PANs never enter your cloud accounts | Often SAQ A or A-EP | Depends on how the token is obtained; a QSA should confirm no PAN passes through your systems, including logs and support tools |
| Card-present terminals connected through a cloud-hosted back office | B-IP, C, P2PE or D | Decided by the terminal type and whether the back office ever sees PANs; a validated P2PE solution is the cleanest reduction |
| Service provider hosting or processing card data for other organisations in the cloud | ROC, or SAQ D for Service Providers | Level 1 needs a ROC; Level 2 may self-assess, with additional service-provider requirements such as six-monthly segmentation testing |
The SAQ A criteria deserve one specific comment because they changed. Since the revised v4.0.1 SAQ A took effect in 2025, Requirements 6.4.3 and 11.6.1 are no longer completed inside SAQ A, but a new eligibility criterion requires the merchant to confirm the site is not susceptible to script attacks, either by applying techniques like those in 6.4.3 and 11.6.1 or by obtaining confirmation from the compliant provider whose embedded payment solution includes such protections. In practice a cloud-hosted marketing site with an embedded payment iframe still has to answer that question. The current SAQ documents and instructions are on the PCI SSC document library.
Why "We Are on AWS, So We Are SAQ A" Is Wrong
The reasoning usually goes: the cloud provider is a validated Level 1 service provider, we have outsourced our infrastructure to it, therefore we have outsourced our cardholder data handling and qualify for SAQ A. The first two statements are true. The conclusion does not follow.
SAQ A eligibility is about outsourcing cardholder data functions, meaning the capture, transmission, processing and storage of card data, to a compliant third party. A hosting provider gives you compute, storage and network. If your application on that compute receives a PAN, you are handling cardholder data, and the provider's validation covers the platform underneath you, not the application you built on it. The provider's Attestation of Compliance and responsibility matrix let you inherit controls such as physical security and hypervisor patching. They do not move you between SAQ types, and they do not change your level.
Our PCI DSS in the Cloud guide covers the shared responsibility model for AWS, Azure, Google Cloud and Alibaba Cloud in detail, including where each provider publishes its AOC and matrix.
A useful test: if you deleted your cloud account tomorrow, would any card data disappear with it? If the answer is yes, whether in a database, an object store, a log or a queue, you are handling cardholder data and SAQ A is not available.
What a Level 1 ROC Looks Like When the Environment Is in the Cloud
A ROC for a cloud-hosted environment follows the same standard and the same reporting template as any other. What changes is the shape of the evidence. Three things happen at the start of a well-run cloud engagement:
Scope is defined in cloud terms. The scope document, network diagram and data-flow diagram describe accounts or subscriptions, regions, virtual networks, managed services and the identities that connect them. A diagram drawn for an on-premises data centre and annotated with a cloud logo is a finding waiting to happen.
The provider's documents are obtained first. The QSA asks for the provider's current AOC and responsibility matrix, checks that the services and regions you use are within its scope, and records which requirements are inherited. Everything else is evidenced from your environment.
Evidence is pulled from the platform, not photographed. Role assignments, MFA enforcement, logging configuration, retention settings, security-group rules and posture findings are exported or read through APIs, timestamped, and mapped to the requirement and testing procedure they support. Screenshots still have a place for a few items, but a Level 1 assessment run on screenshots alone takes weeks longer and produces evidence that is stale by the time the assessor sees it.
For the provider-specific detail, see the QSA guides to PCI DSS on AWS, Azure, Google Cloud and Alibaba Cloud.
Reducing Scope to Reduce Validation Effort
Because the route is decided by what your systems do with card data, the way to move from SAQ D towards SAQ A, or to shrink a ROC, is to stop your systems touching card data. The cloud makes some of these changes easier than they were on-premises, and none of them are free.
Tokenisation through a validated provider. If the provider captures the PAN and hands your application a token, your cloud environment may fall out of the cardholder data environment entirely. Check that no PAN reaches your logs, error handlers, support tools or analytics pipeline; those are where we find it.
Hosted payment pages and hosted fields. Redirects and provider-served iframes are the basis of SAQ A. Provider-supplied JavaScript that renders fields inside your page can qualify, but only where the provider confirms script protections, and your own page elements must not touch the card data.
Dedicated accounts for anything that remains in scope. Where some card data handling must stay with you, isolating it in its own account or subscription with tested segmentation keeps the rest of your estate out of the assessment.
Validated P2PE for card-present channels. A listed point-to-point encryption solution removes the terminal-to-processor path from your scope and can reduce a card-present merchant to SAQ P2PE.
The honest limit is that scope reduction changes which requirements apply to which systems; it does not remove the obligation to validate, and Requirement 12 governance applies whatever your SAQ type. For a view of how scope drives cost, see what PCI DSS compliance actually costs.
Evidence for Either Route
Whether you complete SAQ D or commission a ROC, the evidence for a cloud environment is the same: identity and access configuration, audit logging and retention, network rules, encryption settings and posture findings, all dated and traceable to the account they came from. EIC built Complium to collect that evidence through read-only integrations, on Azure with Microsoft Entra ID, Azure Activity Logs and Microsoft Defender for Cloud, and on AWS with IAM, CloudTrail, Security Hub and Config. Evidence is mapped to PCI DSS v4.0.1 requirements and reviewed by the assessor in the same platform that produces the ROC, and the integrations request zero write permissions.
For Google Cloud and Alibaba Cloud environments, Complium works today from exported Cloud Audit Logs, IAM policy and Security Command Center findings, or ActionTrail, RAM policy and Security Center exports, uploaded and mapped by the same engine. Native connectors for those platforms are on the roadmap. An SAQ D completed with that evidence set behind it is a much stronger document than a questionnaire filled in from memory, and it is what your acquirer will ask to see if a question arises later.
Frequently Asked Questions
Does hosting on AWS, Azure or Google Cloud change whether I need an SAQ or a ROC?
No. Where your environment is hosted has no bearing on the validation route. Your merchant level, set by your acquirer and the card brands on transaction volume, and the way you accept and process card data determine whether you complete a Self-Assessment Questionnaire or need a Report on Compliance from a Qualified Security Assessor. A Level 1 merchant hosted entirely in the cloud still needs a ROC; a small merchant using a hosted payment page still completes an SAQ.
Can I use SAQ A if my website is hosted in the cloud?
Only if your payment acceptance meets the SAQ A eligibility criteria, which are about the payment channel, not the hosting. SAQ A applies to card-not-present merchants that fully outsource all cardholder data functions to PCI DSS compliant third parties, whose website either redirects to the third party or embeds its payment form, and who have confirmed their site is not susceptible to script attacks. A website that meets those conditions is SAQ A eligible whether it runs on a cloud platform or on your own server. A website that handles card data itself is not SAQ A eligible on any platform.
Which SAQ applies if my own payment application runs on cloud virtual machines or containers?
SAQ D for Merchants. If your application receives, processes, stores or transmits cardholder data, you operate systems inside the cardholder data environment and the reduced-scope SAQs do not apply. SAQ D covers every applicable PCI DSS requirement, so the effort is close to a ROC in content, but self-attested. Tokenising through a validated provider so that card data never enters your cloud environment is the usual way to move from SAQ D to SAQ A or A-EP.
Does the cloud provider's Attestation of Compliance count towards my SAQ or ROC?
It is an input, not a replacement. The provider's AOC and responsibility matrix show which requirements the provider covers for the infrastructure and services it operates. Your assessor, or you when completing an SAQ, marks those as inherited and evidences every other requirement from your own configuration, identity design, logging, application and processes. Requirements 9 for your own premises and 12 for policies and processes are never covered by a hosting provider.
We are a service provider hosting card data for other companies in the cloud. SAQ or ROC?
It depends on your service-provider level, which the card brands set on transaction volume. Level 1 service providers need a ROC and AOC produced by a QSA. Level 2 service providers may complete SAQ D for Service Providers, although many customers and acquirers ask for a QSA-signed ROC regardless. In both cases, PCI DSS v4.0.1 also requires you to support your customers' penetration testing and to document which requirements you manage on their behalf.
Can a QSA help with an SAQ, or is a QSA only for a ROC?
A QSA is only mandatory for a ROC, but many organisations engage one for an SAQ. The most common reasons are confirming which SAQ applies, validating scope in a cloud environment, and reviewing cloud configurations before the self-attestation is signed. For SAQ D in particular, where all requirements apply, QSA involvement is common because the questionnaire is close to a full assessment.
If you are unsure which route applies to a cloud-hosted environment, our PCI DSS compliance assessment service starts with a scoping call that settles the level, the SAQ type or ROC, and the scope before any assessment work begins. The standard itself is covered in depth in our complete PCI DSS guide.