PCI-DSS and SOC 2 for Kubernetes

What PCI-DSS and SOC 2 actually demand of a platform team, why scoping and segmentation is the highest-leverage decision you make, and how the requirements map onto Kubernetes primitives you already run.

Overview

Compliance as translation plus evidence

Compliance frameworks arrive on a platform team as questions from someone who does not use Kubernetes, and the instinct is to treat them as paperwork. That instinct produces the annual scramble: three weeks of screenshots, a spreadsheet of exceptions, and controls that exist for the audit rather than the system.

The better framing: PCI-DSS and SOC 2 ask for properties a well-run platform should have anyway, in a vocabulary designed for auditors. The engineering work is translation plus evidence.

Two structurally opposite frameworks

Kind — Prescriptive standard — Attestation
Who sets it — PCI Security Standards Council: twelve requirements under six goals — You define the controls; a CPA firm examines them against the AICPA Trust Services Criteria
Applies to — Anything that stores, processes or transmits cardholder data — The system you describe
How it is checked — An assessor checks your implementation against the requirement text — An opinion on your controls
Checklist — Yes — None: easier to start, harder to do honestly

Type I versus Type II

Customers ask for Type II because a control designed but not operated is worth nothing.

> [!TIP] The exception list is the only part of the report that tells customers anything they could not have guessed.

Scoping is an architecture decision

For PCI, scope is the cardholder data environment plus everything connected to it or capable of affecting its security. In a flat cluster that is the entire cluster and every team on it.

Segmentation shrinks the population you must protect and, more importantly, the population you must prove things about every single year.

> [!WARNING] Teams that fight this decision spend the rest of their audit life arguing about NetworkPolicy semantics with an assessor.

Mapping onto Kubernetes primitives

Once scope is settled, the mapping is mostly mechanical.

Network segmentation — Default-deny NetworkPolicy
Encryption in transit — TLS, including east-west
Encryption at rest — etcd encryption with a KMS-backed key
Access — RBAC least privilege bound to SSO groups, MFA, short-lived credentials
Prevention — Admission control as a gate
Vulnerabilities — Image scanning with an enforced patch SLA
Logging — API audit logs shipped off-cluster with retention

> [!NOTE] The CIS benchmark and Pod Security work are covered under kubernetes-security, policy-as-code and kubescape-runtime-security. Those are the controls; this topic is which requirement each answers and how you prove it operated.

Where interviewers push

The frameworks — The difference without hand-waving
Scope — That it is chosen, not given
Control types — Preventive versus detective, and why it matters over a Type II period
Change management — How GitOps satisfies it and, critically, what breaks it
Evidence — What an auditor actually asks for: a complete population, not a screenshot

Key concepts

Cardholder data environment (CDE): The people, processes and system components that store, process or transmit cardholder data or sensitive authentication data, plus any component connected to them or that could affect their security. Everything in the CDE must satisfy all twelve PCI-DSS requirements. Its boundary is defined by connectivity and data flow, which is why an undocumented network path silently expands it.
Scope and segmentation: Segmentation is the use of network controls to isolate the CDE so that out-of-scope systems are demonstrably out of scope. It is not required by PCI-DSS but it is the single most effective way to reduce cost, risk and assessment effort. The controls must be proven effective, not merely configured; service providers test segmentation at least every six months and after any change to it.
Trust Services Criteria: The AICPA criteria a SOC 2 engagement is performed against, across five categories: security, availability, processing integrity, confidentiality and privacy. Security is the common criteria and is always included; the other four are elective. You select categories based on the commitments you make to customers, since every included category expands what the auditor tests.
Type I versus Type II: Type I is an opinion on whether controls are suitably designed as of a specified date. Type II is an opinion on whether they operated effectively throughout a period, typically three to twelve months, based on sampling. Type II reports carry an exception list, which is the substantive part. Customers ask for Type II because design without demonstrated operation is unverifiable.
Preventive versus detective control: A preventive control makes the violating state impossible — an admission webhook that rejects a privileged Pod. A detective control observes that it happened — a scanner that reports the privileged Pod after the fact. Preventive controls have no exception window and therefore produce cleaner Type II evidence, but they fail closed and must be operated as production-critical infrastructure.
Encryption at rest for etcd: Kubernetes encrypts resources in etcd via an EncryptionConfiguration passed to kube-apiserver with --encryption-provider-config. Only the first key of the first provider encrypts new writes; every configured provider and key is tried on read, which is what makes rotation possible. Rotation requires rewriting existing objects after the new key is primary. The kms provider, with KMS v2, keeps key material outside the config file and is what an assessor expects to see.
API audit logging: kube-apiserver emits audit events per request across the RequestReceived, ResponseStarted, ResponseComplete and Panic stages, at a level of None, Metadata, Request or RequestResponse set by an audit policy file. Written to disk by the log backend or shipped by the webhook backend. Compliance value depends on shipping it off-cluster immediately, since a log that a cluster-admin can delete is not evidence.
Evidence and population: Auditors sample from populations. They ask for every production change in the period, every account with privileged access, every vulnerability finding, then test a sample. The hard part is producing a complete and defensible population, which is a data-pipeline problem. Continuous compliance means those queries run all year, not the week before fieldwork.

When to use it

A payments, fintech or e-commerce platform where any component touches cardholder data — PCI scope is determined by connectivity, so this decision arrives whether or not anyone plans for it
A B2B SaaS product where enterprise procurement blocks on a SOC 2 Type II report, which in practice means the observation window starts months before the deal closes
Designing a new cluster topology, because segmentation is nearly free at design time and extremely expensive to retrofit onto a flat production cluster
Choosing between preventive and detective controls, where the compliance cost of a detective control over a twelve-month Type II period is usually what settles the argument
Building the evidence pipeline — audit log retention, access review automation, change records — which should be designed once rather than reconstructed annually

Interview questions

Explain the difference between PCI-DSS and SOC 2, and what each actually demands of a platform team.
How do you scope a Kubernetes cluster for PCI, and why is segmentation the highest-leverage decision you can make?
Map the framework requirements onto Kubernetes primitives. Walk me through the controls you would implement.
How does GitOps satisfy change management requirements, and what breaks it?
What is the difference between a preventive and a detective control, and why does an auditor care so much?
What do auditors actually ask for, and how do you make evidence collection continuous rather than an annual scramble?