PCI DSS Compliance on AWS: Which Accounts Are Actually in Scope?

AWS published a PCI DSS deep dive for its Security Reference Architecture on 14 September. Most of it is what you would expect: a multi-account layout, SCPs, Config, a log archive. The line that matters is in the scoping section. The Security Tooling, Log Archive, Network and management accounts are all listed as in scope for the assessment, as "connected-to" or "security-impacting" systems. Not the payments account. The accounts around it.

That is the opposite of how most fintech teams we meet have drawn their PCI DSS compliance on AWS. The usual picture has one account with the card-handling service in it, and everything else out of scope because it never sees a PAN. The QSA then spends the first week redrawing the picture, and the team spends the next quarter retrofitting controls onto accounts they thought did not count.

Our position: draw the bigger scope yourself, before the assessor does, and use account boundaries to make the smaller one defensible where it genuinely is.

Why is scope the whole argument in PCI DSS compliance on AWS?

Because every one of the twelve requirements applies to whatever is in scope and none of them applies to what is not. One account with three services in it is a manageable list. Your whole organisation is a different company.

The PCI Council's scoping model has three categories, and the AWS guide maps them onto accounts. Category 1 is the cardholder data environment itself: anything that stores, processes or transmits cardholder data, or sits in the same network segment as something that does. Category 2 is connected-to and security-impacting: anything with a path to the CDE, or that provides a security service to it. Category 3 is out of scope, and the bar is high: a component qualifies "only if it is fully isolated from the CDE — no connectivity path exists, and it provides no security services to the CDE."

The guide's whiteboard test: if someone compromised this account, could they reach cardholder data or weaken the controls around it? If yes, it is in.

Which of your accounts are in the cardholder data environment?

Fewer than you fear, if you have built for it. The guide recommends a dedicated PCI Workloads OU with one CDE account per payment flow: private subnets only, all traffic through the Network account, KMS keys that exist only in that account, and SCPs on the OU that deny the actions which would widen scope: peering to a non-PCI account, disabling CloudTrail, attaching an internet gateway. Alongside it sit connected-to accounts such as a tokenisation service or a fraud engine, which never hold a PAN but are held to the same access, logging and patching controls.

Two things go wrong here. The first is the shared VPC: the card service was built into the same VPC as the rest of the platform, and the whole VPC is now Category 1 because of the "same network segment" clause. The second is the deploy role. A CI runner in a tooling account can assume a role in the CDE account, so the tooling account is connected-to. We wrote about what a fork can do with that runner; the assessor gets to ask the same question.

Why are the logging, network and identity accounts in scope too?

Because the CDE depends on them. The Log Archive account holds the CDE's audit trail, and the integrity of that trail is itself a Requirement 10 control. The Security Tooling account runs the GuardDuty and Config that watch the CDE. The Network account carries the traffic; the management account holds the SCPs. Compromise any of those and you can blind, reroute or open up the CDE without touching a PAN, so the guide puts all four in scope. Shared Services is case by case. If IAM Identity Center lives there and hands out permission sets into the CDE, it is in, and so is the identity provider behind it.

So if you run a landing zone, the honest scope is five or six accounts, not one. What PCI DSS wants on them is what a landing zone should already have: an organisation trail, Config in every region, MFA on every human, no long-lived keys. If the RBI's 2026 direction already made you centralise logs, most of Requirement 10's work on the log account is done.

What does the RBI ask of a payment aggregator, on top of PCI DSS?

If you are a payment aggregator in India, PCI DSS is not a customer's request; it is a licence condition. The RBI's Master Direction on Regulation of Payment Aggregators of 15 September 2025 says in Annexure 1 that data security standards "like PCI-DSS, PCI-SSF, latest encryption standards, transport channel security, etc., shall be implemented", and lists the PCI DSS Attestation of Compliance and Report on Compliance among the documents the annual cyber security audit covers. Paragraph 9(d) makes that an annual audit by a CERT-In empanelled auditor.

Two more clauses shape the layout. Annexure 1, section 2.1 says card credentials "shall not be stored within the database or the server accessed by the merchant", which constrains where the merchant-facing API sits relative to the vault. And paragraph 9(c) applies the 2018 data storage circular, so the CDE, its backups and its logs stay in India. We covered where payment data leaves the country without anyone deciding it should; every one of those leaks is also a scope problem, because the monitoring vendor receiving the logs is now connected-to. A QSA and a CERT-In auditor will both look at the diagram. Draw one that satisfies both.

Does "we never store card data" take you out of scope?

No, and it is the most common misunderstanding we hear. Scope is store, process or transmit. A checkout page that posts the PAN to your API, which forwards it and never writes it down, has processed and transmitted it. The API, the load balancer, the WAF, the subnet, the access log that might capture a request body: all Category 1.

What genuinely shrinks scope is not touching the PAN at all: hosted fields or a redirect, so the card number goes from the browser to the processor and you only ever see a token. Then the CDE can be close to empty. That is a product decision as much as an infrastructure one, and it is the biggest lever a fintech has. If the business will not allow it, the answer is the layout above, with a vault account that is the only place a PAN exists at rest, under a key no other account can use.

What can you run on Monday to find out where your scope really ends?

Two checks. Both take an hour.

The first is the guide's own recommendation: a pci-scope tag on every resource, with the values cde, connected-to or out-of-scope, and the managed required-tags Config rule to flag anything without one. Run it in each account that could be in scope:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "pci-scope-tag-required",
  "Source": { "Owner": "AWS", "SourceIdentifier": "REQUIRED_TAGS" },
  "InputParameters": "{\"tag1Key\":\"pci-scope\",\"tag1Value\":\"cde,connected-to,out-of-scope\"}",
  "Scope": { "ComplianceResourceTypes": [
    "AWS::EC2::Instance", "AWS::EC2::VPC", "AWS::RDS::DBInstance", "AWS::S3::Bucket"
  ] }
}'

It will not stop anyone creating an untagged resource; the rule's documentation says so. What it does is tell you what nobody has classified, and the first run is usually a long list. That list is your real inventory for Requirement 12.5.1, which wants every in-scope component listed with its function.

The second is the connectivity check. In each account you believe is the CDE, create an IAM Access Analyzer external access analyser with the account, not the organisation, as its zone of trust. Anything outside the zone of trust is external, so every sibling account that can assume a role, read a bucket or use a KMS key in the CDE shows up as a finding:

aws accessanalyzer create-analyzer --analyzer-name cde-scope --type ACCOUNT
ARN=$(aws accessanalyzer list-analyzers --query "analyzers[?name=='cde-scope'].arn" --output text)
aws accessanalyzer list-findings --analyzer-arn "$ARN" \
  --query "findings[?status=='ACTIVE'].[resourceType,resource,principal.AWS]" \
  --output table

Every account id in the third column is connected-to, whether you meant it or not. External access analysers are per region, so run it wherever the CDE has resources.

When is one account the honest answer?

Sometimes. A seed-stage company whose processor does the card handling does not need a PCI Workloads OU, a Network account and a Log Archive account. It needs hosted fields, a self-assessment questionnaire and one well-run account. Building the full reference architecture at that stage buys nothing the assessor asked for. We have told teams this and lost the engagement, and it was still the right advice. The line is the first time a PAN touches something you run, or the first time an acquirer or the RBI asks for a Report on Compliance rather than a self-assessment.

The other concession is that account boundaries are not magic. A cross-account role, a shared Transit Gateway route table or a permission set in Identity Center dissolves the boundary in one line of policy. The guide's answer is SCPs that deny the actions creating those paths, plus a data perimeter so in-scope resources only accept in-scope identities from in-scope networks. The same applies to people: if a DevOps partner runs the account, their access path is in scope, and the outsourcing contract has to say what they can reach.

The short version

Draw your five accounts, not your one. Tag everything with pci-scope and let the Config rule tell you what nobody classified. Run an account-level Access Analyzer in the CDE and treat every account id it returns as connected-to. If the business can move to hosted fields and a token, do that first; it removes more scope than any control does. If it cannot, build the PCI Workloads OU with SCPs that make the out-of-scope claim true. Do it before the assessment, when the fix is a Terraform change rather than a finding.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.