Episode 55 — Scope Serverless and Containerized Workloads Without Gaps.
In this episode, we’re going to work through a challenge that keeps showing up as payment environments modernize: figuring out what is in scope when parts of the system are serverless and parts are containerized. For brand-new learners, the tricky part is that these words can make the environment feel abstract, like there are fewer machines and therefore fewer security responsibilities. In PCI work, the opposite is often true. The technology may reduce how much infrastructure you manage directly, but it can also increase complexity in data flow, identity, configuration, and shared responsibility. That is where gaps appear, because the organization assumes the platform handles security while the platform assumes the organization configures security. In a Payment Card Industry Data Security Standard (P C I D S S) assessment, scoping is not about naming technologies; it is about tracing where the Primary Account Number (P A N) is processed, transmitted, or stored and where systems can impact the security of that path. If you can build that mental model, you can scope serverless and containerized workloads in a way that is clear, defensible, and resistant to surprise drift.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
A good starting point is to separate two ideas that often get mixed together. One idea is where the payment data goes, meaning the path that data follows through services and components. The other idea is what can affect that path, meaning the systems and configurations that can change how the data is handled, protected, or exposed. In scoping, both matter. If P A N passes through a service, that service is likely in scope, but the systems that can change that service’s behavior can also become in scope because they can weaken controls or create a new exposure route. In modern environments, those influencers can include build pipelines, container registries, identity policies, network routing rules, secrets management systems, and monitoring platforms. Beginners sometimes assume in scope means directly touches card data, but a Qualified Security Assessor (Q S A) also cares about indirect impact. If a service can deploy new code into a payment function, or if an admin console can change network paths, then it can meaningfully affect the security of the Cardholder Data Environment (C D E) even if it never stores P A N. Scoping without gaps means you capture both the data path and the control plane that governs the data path.
Serverless workloads can create scoping confusion because there is no obvious server to point to. The execution environment is provided by a cloud platform, and code runs in response to events, such as an incoming web request or a message arriving in a queue. That can lead teams to say the platform owns the security, but the platform typically owns only the underlying infrastructure security, not the security of your code, your data handling decisions, and your configuration. The security boundary becomes more about permissions, event triggers, and data access policies than about a specific operating system you patch. From a PCI perspective, the question becomes whether the serverless function processes or can access P A N, whether it can influence payment decisions, and whether it can be modified through your deployment process. A scoping gap often appears when teams treat a function as a small piece of code and forget it is a production system with inputs, outputs, identity, logging, and change control requirements. When you scope serverless correctly, you treat it like a first-class part of the payment system, not like a magical black box.
Containerized workloads create a different kind of scoping confusion because they feel like lightweight packages that can be moved around easily. Containers do make deployment more portable, but that portability can also allow sensitive workloads to spread across clusters, nodes, environments, and accounts faster than traditional servers would. In PCI terms, that can lead to scope creep when a container that handles payment logic gets deployed into a broader shared environment alongside non-payment services. It can also lead to scope gaps when teams assume a cluster is out of scope because it is labeled development, even though the same images and configurations may be reused in production. Containerization also introduces supporting systems that are easy to forget, such as image registries, orchestration control planes, configuration stores, and service-to-service networking layers. A Q S A will want to know not just where the containers run, but how they are built, where their images come from, how secrets are provided, and how their network access is controlled. Scoping without gaps means you include the container ecosystem that makes the workload possible, not just the runtime itself.
A powerful way to avoid both scope gaps and scope sprawl is to anchor everything to the payment data flow and then map supporting components based on influence. Start with the simplest truthful story of how a payment transaction is initiated and completed, including any hosted payment elements, any internal services that receive payment-related inputs, and any systems that store or forward sensitive values. Then expand outward by asking what can change or observe each step. What identity is used by the code to access databases. What configuration determines where events are routed. What permissions allow a service to read logs or write to storage. What system builds the code package or container image and deploys it. What monitoring system alerts when something unusual happens. This approach prevents two common mistakes. The first mistake is missing a critical component because it did not look like a server. The second mistake is declaring huge portions of the environment in scope simply because they share a platform. If you stay anchored on data flow and influence, you can justify scope boundaries clearly, which makes the assessment more defensible and less chaotic.
Identity and access control are often the central scoping fulcrum for serverless and containerized systems, because permissions become the new perimeter. In traditional environments, network segmentation is often the first scoping story people tell, but in modern architectures, permissions can open doors even when networks are segmented. If a serverless function has permission to read a data store with P A N, then the function’s execution environment is part of the sensitive path regardless of where it runs. If a containerized service account has permission to pull secrets that unlock payment processing systems, then that identity is part of the control story. Beginners often focus on where something runs and ignore what it can access. A Q S A will push on what can access what, because access paths can cross network boundaries through managed services. Scoping without gaps means you map which identities can reach sensitive data and which administrative identities can alter those permissions. You also verify that identities are assigned with least privilege and are reviewed, because over-broad permissions can silently widen scope.
Networking still matters, but the scoping conversation changes in modern environments because network paths can be created and modified rapidly. Serverless services may connect to managed databases, message queues, or external payment gateways, and those connections are governed by configuration and policy. Containerized services may communicate through service meshes, load balancers, and internal routing layers that are more dynamic than traditional static firewall rules. A scope gap appears when an organization assumes that because a service is internal, it is isolated, without validating that isolation. A scope gap also appears when the organization assumes that because a service is in a shared cluster, it is automatically in scope, without checking whether the cluster is truly segmented for sensitive workloads. Scoping without gaps means you verify that sensitive services are reachable only through intended paths, and that non-sensitive services cannot become stepping stones into the C D E. It also means you pay attention to the control plane that can change network behavior, because administrative access to routing and security groups can effectively reshape the C D E boundary overnight.
Data storage in serverless and containerized environments often spreads into more places than teams expect, which is why retention and minimization become tightly connected to scoping. A serverless workflow might write intermediate results to object storage, store events in a queue for retry logic, or log request details for debugging. A containerized application might write temporary files, cache responses, or emit detailed logs that get shipped into a centralized analytics system. If any of those artifacts contain P A N, then storage locations that were assumed to be generic become part of the sensitive data footprint. A Q S A will be cautious about claims that P A N never persists, because even short-lived storage can count as storage if it is written to durable services or backups. Scoping without gaps means you identify where data can land during normal operations, during failure conditions, and during troubleshooting. It also means you verify that logging, metrics, and tracing do not accidentally capture sensitive fields, because those observability systems can become the largest accidental data store in modern environments.
Change control becomes a scoping control in its own right in these architectures, because the ability to deploy new code is the ability to change how data is handled. In serverless systems, a small code update can alter what data is collected, where it is sent, and what third-party endpoints receive it. In containerized systems, a new image tag can introduce a new dependency, enable debug features, or change network communication patterns. A scope gap appears when the deployment pipeline is treated as a general engineering tool rather than as a path into the C D E. If a broad group of developers can deploy to payment functions without strong review, then the environment has a weak link that can bypass many other controls. Scoping without gaps means you include the release pipeline components and roles that can alter payment workloads, because those components influence the security of the C D E even if they do not touch P A N directly. A Q S A will look for evidence that changes are reviewed, tested, approved, and traceable, and that emergency changes do not become permanent exceptions.
Secrets management is another area where scoping can quietly break if it is treated as a convenience layer. Serverless and containerized workloads often rely on secrets for database credentials, encryption keys, application programming interface tokens, and service-to-service authentication. If secrets are distributed broadly, or if many services can read sensitive secrets they do not truly need, then the scope boundary becomes fuzzy and the risk grows. For scoping, the question is not only where the secrets are stored, but who can retrieve them, under what conditions, and how usage is logged. A common gap occurs when organizations store secrets in multiple places over time, such as environment variables, configuration files, and centralized secret stores, and they forget to retire older copies. A Q S A will see that as drift, because it creates hidden access paths into sensitive resources. Scoping without gaps means you identify the authoritative secret source, confirm that access is least privilege, and confirm that services are not carrying unnecessary decryption capability or long-lived credentials that expand the blast radius of a compromise.
Shared responsibility is especially important here because modern platforms often blur the line between what the provider does and what the customer does. A cloud provider may manage the underlying runtime security for serverless and the underlying host patching for container nodes, but the customer still defines who can deploy code, which events trigger execution, which services are reachable, and how data is stored and logged. A gap forms when the organization assumes the provider guarantees compliance just because the provider offers compliant services. A Q S A expects the organization to translate shared responsibility into explicit control ownership and evidence, including what the provider supplies and what the merchant must configure and operate. That includes understanding which services are used in the payment flow and obtaining appropriate provider attestations, but it also includes demonstrating that the merchant’s configurations align with the control requirements. Scoping without gaps means you do not stop at the provider boundary; you map responsibilities across it and prove that both sides are covered.
Monitoring and incident readiness become more challenging in serverless and containerized systems because the environment can be more ephemeral. Containers can be replaced quickly, functions can scale up and down, and underlying instances might not exist long enough for traditional host-based evidence collection. That does not reduce the need for logging; it increases the need for reliable centralized logging and consistent event capture. A scoping gap appears when organizations cannot reconstruct what happened because the runtime disappeared, or because logs are incomplete, or because time synchronization is inconsistent across services. A Q S A will care about whether the organization can detect and investigate suspicious activity in the C D E, regardless of whether compute is long-lived or short-lived. Scoping without gaps means you ensure that the monitoring and logging stack that captures events from serverless and containerized workloads is itself part of the sensitive control story. If that stack can be modified, disabled, or bypassed by the same roles that deploy code, then it becomes a weak link, and it may need to be treated as in scope due to its influence on security outcomes.
One of the most common beginner misunderstandings is thinking that segmentation and scope are purely physical, as if putting a workload in a separate virtual network automatically makes it isolated and therefore safe. In modern environments, isolation is more about policy than about geography. A function in one network can still access data in another network if it has the right permissions and routes, and a container in one cluster can still talk to sensitive services if service policies permit it. Another misunderstanding is thinking that because a workload is small, it is low risk. A tiny serverless function that handles payment tokens can still be a critical control point if it validates transactions or routes data to a gateway. A third misunderstanding is treating development and testing as automatically out of scope without ensuring that sensitive data never enters those environments and that deployment pathways cannot cross boundaries improperly. A Q S A will probe these misunderstandings by asking not what you intended, but what is possible given the current configuration. Scoping without gaps means you treat possibility as part of risk, because attackers exploit what is possible, not what was intended.
As we close, remember that scoping serverless and containerized workloads without gaps is fundamentally about tracing data flow, mapping influence, and validating control planes. You start with where P A N is processed, transmitted, or stored and then expand outward to include any system that can change, expose, or undermine that path, including identity policies, deployment pipelines, secrets management, networking configuration, and logging systems. You avoid the trap of assuming the platform handles everything, and you avoid the opposite trap of treating the entire platform as automatically in scope. Instead, you build a defensible boundary based on data and influence, supported by evidence that isolation and least privilege are real. When you can clearly explain how payment workloads are deployed, how they are accessed, how they are monitored, and how sensitive data is prevented from spreading into unexpected places, you remove the hidden gaps that create surprises during assessments and incidents. That clarity is what lets modern payment environments stay agile without sacrificing the disciplined control that P C I D S S expects.
