PCI DSS Audit Scope: An Evidence Problem, Not a Network One

Search for guidance on a PCI DSS compliance audit and you get readiness checklists: twelve requirements, a gap assessment, a vendor offering to close them. Wrong artefact. An assessor produces a report, and its first question is whether the scope you brought is accurate, documented and derivable.

That bites hardest for teams running their own infrastructure. On a managed platform an attestation you cannot audit draws the line between your responsibility and the provider's. Operate the cardholder data environment yourself and that boundary becomes an engineering artefact — harder, and the only version provable from first principles. The network mechanism is covered in default deny, actually.

Scope is something you assert, not something your network reports

PCI DSS v4.0.1 defines scope in two clauses joined by AND, and the second gets dropped. The requirements apply to the CDE — "system components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data," plus components that do not "but have unrestricted connectivity" to ones that do. And, separately: components "that could impact the security" of that data.

The could-impact clause is a second population, not a softer CDE. It is where a control plane, identity provider or log pipeline is usually argued to land — never touching a primary account number, but deciding what does. The standard's Annual Scope Confirmation text names the pattern: identify systems "connected to or, if compromised, could impact the CDE (for example, authentication servers, remote access servers, logging servers)."

Getting out is harder than it looks — the exit test is counterfactual, not topological. A component is out of scope only if "properly segmented (isolated) from the CDE, such that the out-of-scope system component could not impact the security of cardholder data ... even if that component was compromised." Not *does not* reach the CDE today — could not, having been taken over.

Requirement 12.5.2 fixes who does the work: scope is "documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment." By the entity. Requirement 12.5.2.1 halves that interval for service providers, same minimum elements.

You do not choose between SAQ D and a Report on Compliance

Architecture conversations treat the validation route as a design variable: keep the environment small and a self-assessment questionnaire replaces a full Report on Compliance (ROC). The standard closes that. "Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers)."

The SAQ documentation agrees. PCI SSC's SAQ Instructions and Guidelines v4.0.1 r1 (April 2025) calls the questionnaires "alternate validation tools for merchants and service providers that are not required by an acquirer or payment brand(s) to submit a PCI DSS Report on Compliance (ROC)," and scopes the service-provider form to "service providers defined by a payment brand as eligible to complete an SAQ." Eligibility is set upstream.

The engineering consequence: build the evidence a ROC would consume regardless. Come back SAQ and you have overshot, with the 12.5.2 confirmation happening anyway. Come back ROC having built for SAQ and the derivation gets reconstructed from memory during fieldwork.

Read the ROC template before you build the evidence

The v4.0.1 ROC Template is published, and it says what a Qualified Security Assessor must write down — therefore what you hand over. On scope derivation it splits origination from validation: "the entity is expected to retain documentation to show how PCI DSS scope was determined," kept "for assessor review and for reference during the entity's next PCI DSS scope confirmation activity," while "the assessor validates that the scope of the assessment is accurately defined and documented." A living record, not a fieldwork deliverable.

On sampling it asks whether "standardized processes and controls are in place that provide consistency between each item in the samples — for example, automated system build processes, configuration change detection." That describes a GitOps-managed cluster with admission policy and drift detection. Where every node comes off one pipeline a small sample is defensible; hand-tuned exceptions enlarge it, and size is cost.

Drawing the CDE boundary on infrastructure you operate

One container question is settled. The standard's examples of system components include "instantiations of containers or images," "service meshes with containerized applications, and container orchestration tools." PCI DSS reaches a Kubernetes control plane.

What the list does *not* do is place anything. It is an "include but are not limited to" enumeration establishing category membership. Whether your API server sits in the CDE, in the could-impact population or out of scope is derived under the two-part test and counterfactual exit test, then validated by the assessor.

Click to zoom

The design move that pays is declaring scope as cluster metadata rather than in a spreadsheet: a label carries the determination, annotations who made it and on what basis.

# The label records the placement; the annotations record who decided it, when
# and on what basis, so the next confirmation re-reads the derivation.
apiVersion: v1
kind: Namespace
metadata:
  name: payments-authorisation
  labels:
    pci.scope/category: cde
    pci.scope/basis: stores-processes-transmits
    pci.scope/payment-stage: authorization
    pci.scope/acceptance-channel: card-not-present
  annotations:
    pci.scope/determined-by: platform-security
    pci.scope/determined-on: "2026-08-14"
    pci.scope/evidence-owner: payments-platform
    pci.scope/justification: >-
      Primary account numbers in transit to the acquiring gateway.
---
apiVersion: v1
kind: Namespace
metadata:
  name: marketing-site
  labels:
    pci.scope/category: out-of-scope
    pci.scope/basis: counterfactual-argued
  annotations:
    pci.scope/determined-by: platform-security
    pci.scope/determined-on: "2026-08-14"
    pci.scope/segmented-from: payments-authorisation
    pci.scope/segmentation-test: PT-2026-07-SEG
    pci.scope/justification: >-
      No account data and no path into CDE namespaces. The counterfactual
      claim is only as good as the segmentation test referenced above.

Whether a namespace carries an out-of-scope claim, or the CDE deserves its own cluster, is an engineering design position — the standard adjudicates nothing about namespaces. Let the proof be Requirement 11.4.5: penetration tests on segmentation controls "at least once every 12 months and after any changes to segmentation controls/methods," halved by 11.4.6 for service providers.

The scope-confirmation run, and the six things it cannot do

Once placement is metadata, confirmation becomes a job, not a workshop: enumerate, diff against the last confirmed inventory, fail on drift or on any namespace nobody classified. An unlabelled component is a scope gap, not an implicit out-of-scope.

#!/usr/bin/env bash
# INPUT to the fourth element of Requirement 12.5.2 — identifying system
# components in, connected to, or able to impact the CDE. Not a 12.5.2 run.
set -euo pipefail

CONFIRMED="${CONFIRMED:-evidence/pci/scope-inventory.confirmed.json}"
OUT="evidence/pci/scope-inventory.$(date -u +%Y%m%dT%H%M%SZ).json"
mkdir -p "$(dirname "$OUT")"

# An undetermined namespace is a finding, not an implicit out-of-scope.
undetermined="$(kubectl get namespaces -o json \
  | jq -r '.items[]
      | select(.metadata.labels["pci.scope/category"] == null)
      | .metadata.name')"
if [ -n "$undetermined" ]; then
  printf 'no scope determination:\n%s\n' "$undetermined" >&2
  exit 2
fi

kubectl get namespaces -l 'pci.scope/category' -o json \
  | jq -S '{ namespaces: [
        .items[] | {
          name:     .metadata.name,
          category: .metadata.labels["pci.scope/category"],
          basis:    .metadata.labels["pci.scope/basis"],
          owner:    (.metadata.annotations["pci.scope/evidence-owner"] // null)
        }
      ] | sort_by(.name) }' > "$OUT"

# 12.5.2 also fires "upon significant change to the in-scope environment".
if [ -f "$CONFIRMED" ]; then
  diff -u "$CONFIRMED" "$OUT" || { echo "scope drift detected" >&2; exit 3; }
fi

echo "inventory written: $OUT"

Now the honest part, because this is where a well-built pipeline starts overclaiming. Requirement 12.5.2 sets seven minimum elements for the scoping validation; the script feeds one. The other six do not live in the cluster:

1. Data flows for the payment stages the standard names — authorization, capture settlement, chargebacks, refunds — and the acceptance channels: card-present, card-not-present, e-commerce.
2. Data-flow diagrams updated per Requirement 1.2.4.
3. All locations where account data is stored, processed and transmitted, including locations outside the currently defined CDE, applications processing cardholder data, transmissions between systems and networks, and file backups.
4. All segmentation controls in use and the environments the CDE is segmented from, with justification for those environments being out of scope.
5. All connections from third-party entities with access to the CDE.
6. Confirmation that every identified flow, location, component, control and connection is in scope.

The fifth item is the one an automated inventory never sees: a third-party connection into the CDE is a contract before it is a route. That binds this to third-party risk when one vendor runs your whole platform.

Two targeted risk analyses, and they are not interchangeable

PCI DSS v4.0.1 contains two things called a targeted risk analysis, routinely conflated, and even their annual clocks differ. Requirement 12.3.1 requires "review of each targeted risk analysis at least once every 12 months", and an updated analysis only when that review says one is needed; 12.3.2 requires the analysis itself to be performed at least once every 12 months.

Requirement 12.3.1 is the frequency analysis, and it applies "for each PCI DSS requirement that specifies completion of a targeted risk analysis" — in v4.0.1 those are 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1 and 12.10.4.1, not any interval an engineer picks. (11.6.1 invokes one only if you decline its at-least-weekly option.) It justifies the number chosen, in six enumerated contents — the assets protected; the "threat(s) that the requirement is protecting against"; the "factors that contribute to the likelihood and/or impact"; an analysis "that determines, and includes justification for, how the frequency or processes defined by the entity" minimize them; "review of each targeted risk analysis at least once every 12 months"; and "performance of updated risk analyses when needed."

An artefact stopping at assets, threats and likelihood factors is three-sixths of a requirement; the forgotten pair is the last two.

# Targeted risk analysis under PCI DSS v4.0.1 Requirement 12.3.1, setting the
# frequency 10.4.2.1 leaves to the entity: periodic log review for the system
# components outside 10.4.1's daily-review set.
tra_id: TRA-2026-004
register_ref: PCI-TRA-REGISTER#4
sets_frequency_for: 10.4.2.1 periodic log review frequency
version: 3

assets_protected: # 1
  - logs from connected-to namespaces that fall in none of 10.4.1's four populations
  - reporting and reconciliation apps reading tokens only, holding no CHD/SAD

threats: # 2
  - a compromise on a connected-to component unread until the assessment
  - log tampering on a component no one reviews on a schedule

likelihood_and_impact_factors: # 3
  change_rate: continuous delivery; these namespaces change daily
  blast_radius: token-only reads; no CHD/SAD path and no CDE admission authority
  detection_gap: alerting covers known patterns; review catches the rest
  compensating: 10.4.1 covers security events, CHD/SAD, critical and security-function systems daily

resulting_analysis: # 4 - the chosen frequency, and why it is defensible
  entity_defined_frequency: weekly
  justification: >-
    These components are none of 10.4.1's four daily populations: no security
    events, no CHD/SAD, not critical system components, and no security function
    performed. Weekly review bounds the unread window to seven days.

review: # 5 - review of THIS analysis, at least once every 12 months
  interval: P12M
  last_reviewed: "2026-08-14"
  conclusion: results-still-valid

updated_analysis: # 6 - performed when the review says one is needed
  trigger: annual review concludes results-no-longer-valid
  last_update_performed: "2025-11-02"

The daily scope-confirmation run above is deliberately not the subject. Requirement 12.5.2 specifies no targeted risk analysis — it fixes its own floor at 12 months and upon significant change — so a daily diff is an engineering choice stricter than the standard, not a frequency 12.3.1 obliges anyone to justify.

Requirement 12.3.2 is the other one, and not about frequency. It applies where a requirement is met with the customized approach and demands "documented evidence detailing each element specified in Appendix D ... (including, at a minimum, a controls matrix and risk analysis)," plus "approval of documented evidence by senior management." A governance commitment, not an engineering shortcut.

Where tokenisation removes scope and where it only moves it

Tokenisation is sold as scope reduction, and it can be — but not in the direction most architecture diagrams imply. PCI SSC's Tokenization Guidelines (Information Supplement v2.0, August 2011 — the Council's tokenisation scoping document, written against a much earlier standard and never revised for v4.x) is unambiguous: "all components of a tokenization system are considered part of the CDE and are always in scope."

Always. Self-hosting a vault does not take it out of the assessment; it puts a permanently in-scope, cryptographically sensitive system under your operation. Scope comes off downstream, under three simultaneous conditions. Per that same August 2011 supplement, components "adequately segmented (isolated) from the tokenization system and the CDE; and that store, process or transmit only tokens; and that do not store, process, or transmit any cardholder data or sensitive authentication data" may be "possibly out of scope."

Read the qualifiers, not the headline. Segmented from *both* the tokenisation system and the CDE — a de-tokenisation API reachable from analytics breaks that alone. "Only tokens" — one legacy export carrying a truncated account number beside the token breaks the second. "Possibly" is the Council declining to grant the outcome in advance.

A token vault is a key-management problem before a scope problem — the discipline in Kubernetes secrets are still broken, except that here the key material stands between a token table and a breach notification.

How a self-drawn boundary fails

Four failure modes recur in the requirements themselves, each with an instrument.

Scope drift between confirmations. 12.5.2 fires annually *and* "upon significant change to the in-scope environment" — a clause assuming someone notices. Where namespaces are self-service and confirmation is a calendar event, drift surfaces during fieldwork. The instrument is the scheduled diff above, promoted from report to gate: admission policy rejecting an unclassified namespace turns a finding into a rejected pull request.

Sampling collapse. A weak answer to the standardisation question — no automated build process, no configuration change detection — leaves the assessor unable to argue that one sampled node represents the rest. Sample size grows, fieldwork grows, and engineers answer the same question forty times.

Evidence that cannot be re-derived. A screenshot proves a state existed when taken. The template expects the derivation retained "for reference during the entity's next PCI DSS scope confirmation activity" — next year reads this year's reasoning. Evidence that cannot be regenerated from source expires, a discipline covered in Kubernetes audit logs into a SIEM you operate.

A stale segmentation test. 11.4.5 requires the test after "any changes to segmentation controls/methods," not merely annually — and a network policy change is a change to a segmentation control. Treat the pen test as yearly procurement, change policy in month three, and the boundary goes unproven for nine months. Let the policy repository decide when to re-prove it.

Click to zoom

The exit ramp: evidence that outlives the substrate

The argument for owning the cardholder data environment is not that PCI DSS gets easier — it does not. It is that evidence stops being a function of a provider you cannot audit and becomes an artefact you carry.

On a managed platform, much of the scope derivation rests on a document you receive rather than produce. Change provider and it is void: the boundary is re-derived against a new attestation, on someone else's schedule, and the derivation retained for the next confirmation describes a platform you no longer run.

An entity-generated evidence set has no such dependency. The manifest below makes it portable: requirement, artefact, location, content hash, owner. Nothing in the standard asks for it; it makes the next confirmation a diff, not an investigation.

{
  "manifest_version": 3,
  "note": "Entity control-evidence register. Serves 12.5.2 re-confirmation and the ROC sampling rationale. NOT the assessment-evidence repository in the ROC template's retention section.",
  "entries": [
    {
      "requirement": "12.5.2",
      "element": "system components in, connected to, or able to impact the CDE",
      "artefact": "scope-inventory.20260814T090411Z.json",
      "repository": "git+ssh://git.internal/evidence/pci",
      "sha256": "0f9a5c1e7d3b46a2988c0e5f14b7d3a6c2e918f4b70d5a3c6e2f1b849d0c7a35",
      "collected_at": "2026-08-14T09:04:11Z",
      "owner": "platform-security",
      "regenerable": true,
      "regenerate_with": "make evidence/scope-inventory"
    },
    {
      "requirement": "11.4.5",
      "element": "penetration test of segmentation controls",
      "artefact": "segmentation-pentest-2026-07.pdf",
      "repository": "s3://evidence-store/pci/11.4.5/",
      "collected_at": "2026-07-22T14:35:02Z",
      "owner": "security-assurance",
      "regenerable": false,
      "triggers": ["annual", "change to segmentation controls or methods"]
    }
  ]
}

The regenerable field is the point. An artefact regenerable from source survives a substrate change; one that is not is a fossil of a platform you may no longer run. Sort evidence by that column and you have a migration plan nobody had to write — the optionality logic behind ISO 27001 without inherited controls and SOC 2 on self-hosted Kubernetes.

One piece of timing, because the document still states it in the future tense. The future-dated applicability notes read: "this requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment." That date is behind us — those requirements are in force now, and a plan treating them as upcoming is reading an expired calendar.