PaysecVisit Website →
← Back to blog

PCI Segmentation in the Cloud: A Practical Guide

October 20, 2026
PCI Segmentation in the Cloud: A Practical Guide

PCI segmentation in the cloud means isolating the systems that store, process, or transmit card data from everything else, using virtual networks, separate accounts, firewalls, and routing rules. Done well, it shrinks the number of systems an assessor has to examine. Done poorly, a flat network can pull every connected system into scope. The PCI Security Standards Council (PCI SSC) scoping guidance says segmentation is strongly recommended but is not itself a PCI DSS requirement. It is a way to make compliance smaller, cheaper, and easier to prove.

This guide covers how segmentation works on AWS and Google Cloud, what evidence assessors expect, how ASV scans fit in, and how SAQ A and SAQ A-EP relate to your scope. It is written for restaurant groups, healthcare practices, ecommerce owners, and SaaS platforms that run payments on cloud infrastructure.

Paysec
Make Payment Costs More Transparent
PaySec offers Network Offset Pricing, detailed transaction reporting, and flexible payment options for businesses seeking clarity on processing fees.
Explore PaySec

TL;DR

  • Segmentation is optional, but scope is not. Everything connected to the cardholder data environment (CDE) is in scope until a Qualified Security Assessor (QSA) validates otherwise.
  • A label is not a boundary. A system is out of scope only if its compromise cannot affect the CDE. Separate subnets alone do not prove that.
  • Layer your controls. Use dedicated accounts or projects, private networks, explicit traffic rules, and organization-level guardrails.
  • The cloud provider covers only its share. You remain responsible for your own configuration and testing.
  • The best scope reduction is less card data. Tokenization and a hosted payment flow keep raw card numbers out of your systems from the start.

Table of Contents

What segmentation does, and what it does not

The PCI SSC defines the idea simply: separate the cardholder data environment from systems that do not need to touch card data. The separation can be physical or logical. Firewalls, access-control lists, routing restrictions, and virtual networks are all valid tools.

The payoff is real. According to the same guidance, proper segmentation can reduce assessment scope, assessment cost, control-implementation effort, and organizational risk. Without it, a flat network can place the whole connected network in scope.

The central test is impact resistance. A system is meaningfully out of scope only when it cannot affect the security of the CDE even if an attacker controls it. Putting workloads in different subnets or on different virtual machines does not meet that test by itself. Ask this question of every system you want to exclude: if this were fully compromised, could it reach, change, or observe anything in the CDE?

Connected-to systems and security-impacting systems

Three groups of systems typically fall in scope:

  1. Systems that store, process, or transmit card data.
  2. Systems on the same network segment as those systems.
  3. Systems that connect to, or could affect the security of, the CDE. Examples are authentication servers, logging services, DNS, and management consoles.

The third group surprises teams most often in the cloud. An administrative role that can modify CDE firewall rules, or a shared logging pipeline, can bring an otherwise isolated environment back into scope.

How the cloud changes the evidence

In a traditional data center, separate environments are usually separate physical machines. In a public cloud, tenants share infrastructure. The PCI SSC cloud computing guidelines state that isolation must hold across network, operating-system, application, and stored-data layers. They also note that shared components or provider-managed paths that connect in-scope and out-of-scope workloads can bring those components into scope.

That creates a split of duties:

LayerWho proves it
Physical hosts and tenant isolationCloud provider
Virtual network, security groups, routing, accountsYou
Operating system, application, data handlingYou
Provider-managed services in the data pathShared: review the provider's responsibility documentation

AWS describes this directly in its PCI FAQ. AWS is a PCI DSS Level 1 Service Provider, yet the customer remains responsible for its own compliance and must perform additional testing for its own environment. You can use the AWS Attestation of Compliance for the AWS portion of the CDE when your QSA considers it applicable. AWS provides that attestation and the Responsibility Summary through AWS Artifact.

Write the shared-responsibility split down. Assessors ask for it, and it prevents the common mistake of assuming a provider's certification covers your workloads.

Segmentation patterns on AWS

AWS updated its segmentation whitepaper in November 2024 for PCI DSS 4.0 workloads. According to the AWS Security Blog announcement, a good design defines boundaries for both east-west traffic (internal, between workloads) and north-south traffic (to and from the internet). It also gives reference architectures for AWS Organizations, account structure, network patterns, and firewall rules.

The AWS Security Reference Architecture for PCI DSS organizes accounts within one organization across purpose-built organizational units. The design principle is defense in depth:

  • Account-level separation creates an administrative boundary.
  • Network controls enforce which traffic may cross it.
  • Organization guardrails reduce the chance that a later change silently reopens connectivity.

A practical AWS layout

For a SaaS platform or multi-location operator, a workable structure looks like this:

  1. A dedicated CDE account. Only the services that handle card data live here. Fewer people hold access.
  2. Private subnets only. No direct internet route to CDE workloads. Public traffic enters through a controlled front end.
  3. Centralized firewalling. Inspect traffic entering and leaving the CDE account, not just at the instance level.
  4. Restrictive routing. Do not peer or attach the CDE network to out-of-scope networks unless a rule requires it, and document the reason.
  5. Guardrails at the organization level. Block changes that would create public access, new peering, or disabled logging in the CDE account.
  6. Separate administrative paths. Use multi-factor authentication and distinct roles for CDE administration.

This is stronger and easier to evidence than relying on security groups alone. A common forum question asks whether security groups are enough. They are one control. They are rarely the whole story an assessor will want to see.

Segmentation patterns on Google Cloud

Google's architecture guidance on limiting PCI scope recommends a similar approach with different building blocks:

  • Place the CDE in its own dedicated VPC.
  • Use custom-mode networking, so no unintended subnets or routes appear.
  • Enable VPC Service Controls.
  • Use organization policies to prevent the VPC from being shared with other projects.
  • Allow peering only with trusted networks.

The goal is to remove any route that an untrusted system could use to send packets to, or receive packets from, trusted CDE components. The vocabulary differs from AWS, but the logic is the same: separate administrative domain, minimal paths, and policy that prevents drift.

Modern architectures: zero trust, micro-segmentation, multi-cloud

Many teams now run containers, serverless functions, and several clouds at once. The PCI SSC addressed this in its 2023 Special Interest Group update on scoping and segmentation for modern network architectures. It covers zero-trust architectures, micro-segmentation, and multi-cloud environments.

Modern cloud architecture concepts requiring enforceable separation

The takeaway is that no technology is automatically accepted or rejected. The question is whether your controls enforce separation and stop an out-of-scope system from affecting the CDE. If a micro-segmentation policy does that and you can show evidence, it can support your scope decision. If it only labels workloads, it will not.

Keeping evidence: what assessors ask for

A clean design still has to be provable. Prepare:

  • Current network and data-flow diagrams showing every path into and out of the CDE.
  • Firewall and routing rule sets with a reason for each rule.
  • Flow logs and access logs that show blocked and allowed traffic.
  • Change-review records for anything that touches CDE boundaries.
  • Segmentation test results, including penetration tests that try to cross the boundary.
  • The shared-responsibility documentation from each cloud provider.

Cloud-native tooling helps collect this. AWS Security Hub supports PCI DSS v4.0.1 and v3.2.1 controls, and its documentation recommends v4.0.1 for current practice. It can flag configuration gaps. A passing automated check does not by itself establish a compliant segmented architecture, so treat it as monitoring and supporting evidence next to diagrams, flow records, and assessor validation. If you want a framework for tracking those controls and evidence over time, this overview of ISO 27002 controls and compliance tracking is a useful companion.

ASV scans and your segmented environment

An Approved Scanning Vendor (ASV) is a company the PCI SSC has validated to run external vulnerability scans of internet-facing systems. These scans support PCI DSS Requirement 11.3.2. Per the PCI SSC ASV program page and its guidance, in-scope internet-facing environments need scans at least quarterly and after significant changes to internet-facing systems. The council's ASV program overview describes ASVs as approved to scan the internet-facing environments of merchants and others.

What this means for a cloud team:

  1. List your public IP addresses and domains that belong to the CDE or connect to it. Load balancers, API gateways, and VPN endpoints count.
  2. Scan after significant changes, such as a new public endpoint or a new load balancer, not just on the quarterly calendar.
  3. Fix and rescan until the report shows a passing result for your acquirer.
  4. Do not confuse scans with segmentation testing. An ASV scan looks at your external surface. It does not replace internal segmentation validation, penetration testing, or your broader PCI controls.

Segmentation helps here too. A smaller set of internet-facing in-scope systems means fewer addresses to scan and fewer findings to remediate.

SAQ A and SAQ A-EP: scope starts with the payment flow

Many ecommerce merchants never need a full cloud segmentation project, because their payment flow keeps card data off their own servers. The self-assessment questionnaire (SAQ) you qualify for follows from how card data reaches the processor.

  • SAQ A generally fits merchants that fully outsource card data handling, and the payment page is delivered entirely by a validated third party.
  • SAQ A-EP generally fits ecommerce merchants whose website does not receive card data but can affect the security of the payment transaction, for example through a page that controls how the payment form is delivered.

The practical difference is scope. The more your own servers and scripts influence the payment page, the more systems you must protect, scan, and document. Eligibility rules changed in v4.0.1, so check the current criteria before you assume a form. Our PCI SAQ types eligibility checklist walks through each type, and our guide on confirming SAQ eligibility to avoid noncompliance fees explains why the right form matters. For the wider ecommerce picture, see our ecommerce payment stack explainer.

Reduce what you segment: tokenization and hosted payments

The simplest way to shrink scope is to keep raw card data out of your cloud environment altogether. Segmentation limits which systems can talk to payment components. Tokenization limits the value of the data that reaches everything else.

NIST's hospitality reference design, Securing Property Management Systems, shows the combination. Tokens move through the property management system and are used again at checkout, so fewer systems ever handle card data. Segmentation and monitoring then cover the remaining payment components. Restaurants and multi-location operators with POS, reservation, and back-office systems can apply the same logic.

In practice:

  • Capture card data at the edge, in a terminal or a hosted payment field.
  • Store and pass only tokens through order, reservation, CRM, and analytics systems.
  • Keep the systems that can detokenize or reach the processor in a small, segmented zone.

For a deeper look at proving what is out of scope, read our article on PCI scope reduction.

Who this matters for

Restaurant chains. POS terminals, kitchen systems, loyalty apps, and cloud back offices often share networks. Tokenize at the terminal and keep the payment zone small.

Healthcare practices. Patient portals, billing, and payment data sit near protected health information. Clear boundaries make both PCI and privacy reviews easier. See our healthcare payment data security roadmap.

Ecommerce owners. Your choice of checkout integration decides your questionnaire and your scan obligations.

SaaS and marketplace operators. Multi-tenant platforms benefit most from account-level separation and organization guardrails, since one change can affect many customers.

Our perspective: scope less, prove more

We see the same pattern with merchants of every size. Teams spend months designing network boundaries for card data they could have avoided holding at all. The strongest segmentation project starts with a question: which systems truly need card data?

Our view rests on three points.

  • Design the payment flow first. Terminals, a hosted gateway, and tokenization remove card data from most of your stack before any firewall rule is written. PaySec supports in-store processing, an eCommerce gateway, mobile payments, and recurring billing, with PCI DSS Level 1 and SOC 2 compliance behind the platform.
  • Treat evidence as part of the design. Real-time reporting and detailed transaction records make it easier to show what moved where and when.
  • Keep compliance simple for the merchant. We include PCI compliance assistance so merchants can complete validation without building a security team. Our security and encryption overview explains the protections in place.

Segmentation remains valuable where you do run your own payment components. For everyone else, the goal is a small, well-documented footprint.

— PaySec Marketing Team

A short checklist before you call your assessor

  1. Map every system that stores, processes, or transmits card data, and every system connected to them.
  2. Remove card data you do not need, and replace the rest with tokens.
  3. Move the remaining payment components into a dedicated account or project and a dedicated network.
  4. Define east-west and north-south rules, and write the reason for each.
  5. Add organization-level guardrails so future changes cannot quietly open a path.
  6. Collect diagrams, logs, change records, and the provider's responsibility documents.
  7. Test the boundary, then schedule quarterly ASV scans and scans after significant changes.
  8. Ask your QSA to validate the scope decision before you rely on it.

Simplify the payment side with PaySec

If you want fewer systems in scope, start with how you accept payments. PaySec offers merchant services for in-store, online, mobile, ACH, and recurring payments, with no long-term contracts and no monthly minimums. Our Network Offset Pricing passes through true wholesale interchange rates, and our pricing page lists the plan options. Terminals come with free placement at $0 per month. If you are unsure where your business stands, our PCI compliance checklist for small businesses is a good first read.

FAQ

Is network segmentation required for PCI DSS?

No. PCI SSC guidance describes segmentation as strongly recommended but not a requirement. Without it, your whole connected network may be in scope, so most organizations that run their own payment systems adopt it to keep assessments smaller.

Do AWS security groups alone give me PCI segmentation?

They are one control, and a useful one. A stronger design layers them with a dedicated account, private network segments, central firewalling, restrictive routing, and organization guardrails. Your QSA decides whether the combined evidence supports your scope claim.

What is an ASV scan?

It is an external vulnerability scan of your internet-facing systems, run by a vendor approved by the PCI SSC. In-scope environments need one at least quarterly and after significant changes to internet-facing systems. It does not replace segmentation testing or penetration testing.

Is my business PCI compliant if my cloud provider is?

Not automatically. AWS, for example, is a PCI DSS Level 1 Service Provider, but its customers remain responsible for their own compliance and testing. You can reference the provider's Attestation of Compliance for its portion of the environment when your QSA agrees it applies.

What is the difference between SAQ A and SAQ A-EP?

SAQ A generally covers merchants that fully outsource card data handling. SAQ A-EP generally covers ecommerce sites that do not receive card data but can affect the security of the payment transaction. Confirm current eligibility criteria before choosing.

Sources