| Key idea: the fact that AWS Lambda or Cloud Run functions are included within the PCI DSS scope of the cloud provider does not certify the application that the customer deploys on top of them. The provider supplies evidence for the controls it operates; the customer remains responsible for its architecture and for all controls it retains or shares. AWS and Google explicitly describe this within their shared responsibility models. [5–8] |
Therefore, serverless should not be interpreted as "PCI DSS managed by the provider." The correct question is which layers have been transferred to the provider and which layers remain under the entity's control. That responsibility matrix must be mapped requirement by requirement, not only by cloud service.
The greatest challenge often arises before reviewing controls: defining scope. A function is part of the CDE if it stores, processes, or transmits CHD/SAD; components that do not directly handle PAN may also be in scope if they can affect the security of the CDE. Depending on the architecture, this includes API gateways, queues, event buses, secrets services, key management systems, logs, repositories, deployment pipelines, and accounts or projects from which CDE resources can be modified. [1–2]
The ephemeral nature of runtime instances does not eliminate the inventory requirement. In serverless environments, the relevant "asset" is not the temporary container that is created and destroyed, but the logical function and everything that defines its behavior: code, version, layers or libraries, variables, execution role, event sources, policies, secrets, network destinations, logs, and the infrastructure-as-code template. The inventory must be capable of reconstructing the actual environment even when no permanent server exists.
| Component | Scope Criterion | Evidence Worth Maintaining |
| Lambda Function / Cloud Run function | In scope if it processes CHD/SAD or can affect the CDE. | Inventory, code version, configuration, role, and dependencies. |
| API Gateway / endpoint | In scope if it receives or transmits payment data or protects access to the CDE. | Routes, authentication, WAF/controls, encryption, and logs. |
| Queues, events, and temporary storage | In scope if they transport account data or influence the payment flow. | Event schemas, encryption, retention, DLQ, and access controls. |
| KMS / Secrets Manager / Secret Manager | Security component supporting the protection of data and credentials. | Key policies, rotation, permissions, and traceability. |
| CI/CD and Infrastructure as Code | In scope if it can modify code or configuration within the CDE. | Repository, approvals, signatures, pipeline controls, and segregation. |
PCI SSC has been emphasizing for years that outsourcing technology does not equate to outsourcing responsibility. The allocation depends on the specific service, the function it performs, and which controls have been validated by the provider. [3–4] In 2026, AWS includes Lambda among its PCI DSS in-scope services and Google Cloud includes Cloud Run functions, but both remind organizations that they must validate their own solution. [5,7]
In serverless environments, much of the traditional operating system hardening disappears, but Requirements 1 and 2 are still implemented through secure configuration and communication controls. The exposure of endpoints, API Gateway rules, VPC connectors, outbound routes, resource policies, allowed origins, cloud accounts/projects, cloud organizations, and any mechanism that limits which services can communicate with the CDE must be reviewed. In modern architectures, segmentation may rely on the network, identity, service policies, or a combination of these; the result must be verifiable. [2]
Outbound control deserves particular attention. A function with permission to initiate arbitrary connections to the Internet can become an exfiltration channel even if inbound access is heavily restricted. Google's own documentation on tokenization with serverless functions warns that, for certain PCI DSS designs, the lack of granular ingress/egress controls may require compensating controls or an alternative platform. [8]
For Requirements 3 and 4, the priority should be to minimize the presence of PAN. Whenever the business model allows it, tokenizing data before it reaches general-purpose functions reduces scope and complexity. If a function needs to process PAN, encryption in transit, temporary storage, environment variables, parameters, error queues, traces, and logs must be validated. A common mistake is to protect the database while ending up copying the full PAN into logs, APM systems, or debugging messages.
| PCI DSS Domain | How It Translates to Serverless | Typical Risk |
| Protection Against Malicious Software (Req. 5) | Assess the actual risk of the components; strengthen code, artifact, and dependency analysis where no manageable host exists. | Assuming that "there is no server" means there is no malware risk. |
| Secure Development (Req. 6) | Inventory of proprietary software and components, SAST/SCA analysis, IaC review, vulnerability management, and controlled changes. | Vulnerable dependencies or functions deployed outside the approved pipeline. |
| Access Based on Business Need (Req. 7) |
Least-privilege roles per function, resource-specific policies, and separation between deployment, operations, and auditing. | Wildcard roles, inherited permissions, or the same identity used across multiple functions. |
| Identification and Authentication (Req. 8) |
Short-lived workload identities, MFA for administration, and enhanced protection of human credentials. | Permanent keys stored in variables, repositories, or shared secrets. |
In this model, the development pipeline becomes a critical part of the environment. If a repository, a deployment role, or a CI/CD tool can modify a function that processes payments, its potential impact must be analyzed. The security review must cover not only the source code, but also infrastructure templates, dependencies, reusable images or layers, parameters, secrets, and the production promotion mechanism. [1–2,6]
| Test / Evidence | Recommended Approach in Serverless Environments |
| External AS | Apply them to public-facing assets that meet the requirement criteria; do not confuse the absence of self-managed servers with the absence of an external attack surface. |
| Vulnerability Analysis | Combine SCA, artifact analysis, code analysis, infrastructure-as-code review, and cloud configuration assessment. |
| Penetration Testing | Test the business workflow and the relationships between services, not only the public URL. Include identity abuse, permissions, and event-based attack scenarios. |
| Segmentation Validation | Verify that an identity or resource outside the CDE cannot reach or impact protected components. |
| Monitoring | Generate alerts for changes to roles, policies, secrets, functions, event sources, and data paths; correlate application and control plane events. |
| Change Management | Demonstrate approval, testing, segregation of duties, rollback capability, and traceability from commit to deployed version. |
| Audit point: evidence must demonstrate control of the logical environment. Standalone screenshots from the cloud console provide little value if they cannot be linked to inventories, infrastructure-as-code configurations, repositories, change records, and reproducible testing evidence. |
The cloud provider must be managed within the third-party risk management program: confirming its PCI DSS status, verifying that the specific service being used is covered, and retaining documentation that clearly defines responsibilities. The CSP's AOC serves as evidence of the provider’s controls; it does not automatically certify the customer’s workload. [3–5,7]
In addition to the CSP, repositories, CI/CD platforms, observability tools, libraries, and other services that can access account data or affect the security of the CDE must also be assessed. In serverless environments, these third parties often remain outside the initial architecture diagram and only reappear during the audit process. [4]
| Common Mistake | Consequence |
| “Lambda is certified, therefore my solution is compliant" | The provider’s assessment is confused with the assessment of the customer’s environment. |
| Inventory | Functions, events, identities, and ephemeral resources are left out of scope. |
| Over | Privileges and scope expand into seemingly auxiliary services. |
| Manual deployments | Traceability is lost, and environments may continue to impact each other. |
The most efficient way to address PCI DSS in serverless environments is to start with data flows and impact capabilities. At Internet Security Auditors, we propose: discovery and scoping; a responsibility matrix covering the CSP and third parties; a PCI DSS GAP assessment based on the actual architecture; a prioritized Action Plan; support for implementation and scope reduction; technical testing and revalidation; and PCI DSS audit/validation when required.
As a QSA, Internet Security Auditors can support architecture reviews, data flow analysis, IAM assessments, secure development lifecycle reviews, third-party management, risk analysis, ASV services, penetration testing, and compliance audits. The objective is to adapt the standard to the serverless model and focus efforts on the controls that remain under the customer’s management. [9]
More information: PCI DSS Compliance and Certification.
Serverless can simplify PCI DSS compliance, but it does not eliminate it. The platform transfers part of the infrastructure and operational responsibilities to the provider, while increasing the importance of scope definition, identity management, secure configuration, secure development, observability, third-party management, and automated evidence collection.
The right architecture is the one that minimizes PAN exposure, establishes demonstrable boundaries, assigns responsibilities without gaps, and makes it possible to reconstruct which code and configuration were active at any given time. In PCI DSS v4.0.1, the ability to demonstrate compliance is just as important as the technology chosen.
References
[1] PCI Security Standards Council — PCI DSS v4.0.1, current standard and supporting documentation.
[2] PCI Security Standards Council — PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures (2024).
[3] PCI Security Standards Council — PCI DSS Cloud Computing Guidelines v3.0 (2018), informational supplement on shared responsibility and cloud testing.
[4] PCI Security Standards Council — FAQ 1580, applicability of PCI DSS requirements to service providers and shared responsibilities.
[5] Amazon Web Services — AWS Services in Scope by Compliance Program: PCI DSS. AWS Lambda is listed among the included services; page updated on 17/07/2026.
[6] Amazon Web Services — Transforming Transactions: Streamlining PCI Compliance Using AWS Serverless Architecture; and AWS Lambda compliance documentation.
[7] Google Cloud — PCI DSS Compliance. Cloud Run functions / Cloud Functions are included among the assessed services, while customers retain responsibility for their applications.
[8] Google Cloud Architecture Center — Tokenizing Sensitive Cardholder Data for PCI DSS, serverless example and considerations regarding network controls.
[9] Internet Security Auditors — PCI DSS Compliance and Certification: compliance assessment, implementation, QSA audit, ASV services, and ongoing compliance maintenance.
Sources consulted on September 30, 2026. Tables and analysis are the author's own work.