---
title: El reto de PCI DSS en arquitecturas Serverless (Lambda, Cloud Functions)
description: Descubre cómo cumplir con PCI DSS en arquitecturas serverless, enfocándote en AWS Lambda y Google Cloud Functions, y manteniendo la seguridad de los datos.
image: https://blog.isecauditors.com/hubfs/El%20reto%20de%20PCI%20DSS%20en%20arquitecturas%20Serverless.png
---

[![290x123px\_isecauditors](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/290x123px_isecauditors.png?width=290&height=91&name=290x123px_isecauditors.png) ![290x123px\_isecauditors](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/290x123px_isecauditors.png?width=290&height=91&name=290x123px_isecauditors.png)](https://blog.isecauditors.com/)

- [← www.isecauditors.com](https://www.isecauditors.com/)
- [academy.isecauditors.com](https://academy.isecauditors.com/)

- [← www.isecauditors.com](https://www.isecauditors.com/)
- [academy.isecauditors.com](https://academy.isecauditors.com/)

Español

- [Inglés](https://blog.isecauditors.com/en/the-challenge-of-pci-dss-in-serverless-architectures-lambda-cloud-functions)
- [Español](https://blog.isecauditors.com/el-reto-de-pci-dss-en-arquitecturas-serverless-lambda-cloud-functions)

[Cumplimiento PCI DSS](https://blog.isecauditors.com/tag/cumplimiento-pci-dss) [Serverless](https://blog.isecauditors.com/tag/serverless)

# El reto de PCI DSS en arquitecturas Serverless (Lambda, Cloud Functions)

[Alberto Villar Arévalo](https://blog.isecauditors.com/author/alberto-villar)  23 oct 2026, 10:43:43

El objetivo de este artículo es analizar cómo aplicar **PCI DSS v4.0.1** a arquitecturas sin servidor (*serverless*), con especial foco en **AWS** Lambda y *Google Cloud Functions/Cloud Run functions*. Estas tecnologías eliminan de la gestión del cliente gran parte de la infraestructura tradicional, pero no eliminan el **Entorno de Datos de Tarjetas (CDE)**, ni las obligaciones sobre el código, los datos, las identidades, las configuraciones, los flujos, los proveedores y las evidencias que permiten demostrar el cumplimiento. \[1–3\]

**PCI DSS** es tecnológicamente neutral. A septiembre de 2026, la versión publicada vigente sigue siendo **PCI DSS v4.0.1.** El PCI SSC ha reforzado además la orientación sobre arquitecturas modernas, incluyendo entornos *multi-cloud*, microservicios efímeros, infraestructura como código y modelos de segmentación que ya no dependen únicamente de una red física tradicional. \[1–2\]

# SERVERLESS: Qué cambia y qué no cambia

 En una arquitectura tradicional, la organización suele administrar sistemas operativos, máquinas virtuales, agentes de seguridad y buena parte de la red. En un modelo *serverless*, el proveedor opera el sistema operativo, el hipervisor, la plataforma de ejecución y parte de la disponibilidad. El cliente se concentra en la función, su configuración, sus permisos, las integraciones y los datos. Este reparto puede reducir carga operativa, pero también desplaza el riesgo hacia capas lógicas que son fáciles de pasar por alto.

| **Idea clave:** que AWS Lambda o Cloud Run functions estén incluidos en el alcance PCI DSS del proveedor cloud no certifica la aplicación que el cliente despliega sobre ellos. El proveedor aporta evidencias sobre los controles que opera; el cliente continúa siendo responsable de su arquitectura y de todos los controles que conserva o comparte. AWS y Google lo describen expresamente dentro de sus modelos de responsabilidad compartida. \[5–8\] |
| --- |

Por tanto, *serverless* no debe interpretarse como “*PCI DSS gestionado por el proveedor*”. La pregunta correcta es qué capas han sido transferidas al proveedor y qué capas siguen bajo control de la entidad. Esa matriz de responsabilidades debe trazarse requisito por requisito, no únicamente por servicio cloud.

# El alcance PCI DSS en recursos efímeros

El mayor reto suele aparecer antes de revisar controles: definir el alcance. Una función entra en el CDE si almacena, procesa o transmite CHD/SAD; también pueden quedar en alcance componentes que no manejan directamente PAN pero pueden afectar a la seguridad del CDE. Esto incluye, según la arquitectura, pasarelas de API, colas, buses de eventos, servicios de secretos, sistemas de gestión de claves, registros, repositorios, canalizaciones de despliegue y cuentas o proyectos desde los que sea posible modificar recursos del CDE. \[1–2\]

La naturaleza efímera de las instancias de ejecución no elimina la obligación de inventario. En *serverless*, el “activo” relevante no es el contenedor temporal que nace y desaparece, sino la función lógica y todo lo que define su comportamiento: código, versión, capas o librerías, variables, rol de ejecución, orígenes de eventos, políticas, secretos, destinos de red, registros y plantilla de infraestructura como código. El inventario debe poder reconstruir el entorno real aunque no exista un servidor permanente.

| **Componente** | **Criterio de alcance** | **Evidencia que conviene mantener** |
| --- | --- | --- |
| Función Lambda / Cloud Run function | En alcance si procesa CHD/SAD o puede afectar al CDE. | Inventario, versión de código, configuración, rol y dependencias. |
| API Gateway / endpoint | En alcance si recibe o transmite datos de pago o protege el acceso al CDE. | Rutas, autenticación, WAF/controles, cifrado y registros. |
| Colas, eventos y almacenamiento temporal | En alcance si transportan datos de cuenta o influyen en el flujo de pago. | Esquemas de eventos, cifrado, retención, DLQ y controles de acceso. |
| KMS / Secrets Manager / Secret Manager | Componente de seguridad que soporta protección de datos y credenciales. | Políticas de claves, rotación, permisos y trazabilidad. |
| CI/CD e infraestructura como código | En alcance si puede modificar código o configuración del CDE. | Repositorio, aprobaciones, firmas, controles del pipeline y segregación. |

# Responsabilidad compartida: proveedor vs. cliente

PCI SSC lleva años insistiendo en que externalizar tecnología no equivale a externalizar la responsabilidad. La asignación depende del servicio concreto, de la función que desempeña y de qué controles han sido validados por el proveedor. \[3–4\] En 2026 AWS incluye Lambda dentro de sus servicios en alcance PCI DSS y *Google Cloud* incluye *Cloud Run functions*, pero ambos recuerdan que la organización debe validar su propia solución. \[5,7\]

# Requisitos 1–4: Red, configuración y protección de datos

En *serverless* desaparece gran parte del bastionado clásico del sistema operativo, pero los Requisitos 1 y 2 siguen materializándose en configuración segura y control de comunicaciones. Deben revisarse la exposición de *endpoints*, reglas de *API Gateway*, conectores VPC, rutas de salida, políticas de recursos, orígenes permitidos, cuentas/proyectos, organizaciones cloud y cualquier mecanismo que limite qué servicios pueden comunicarse con el CDE. En arquitecturas modernas la segmentación puede apoyarse en red, identidad, políticas de servicio o una combinación de ellas; el resultado debe ser verificable. \[2\]

El control de salida merece especial atención. Una función con permisos para iniciar conexiones arbitrarias hacia Internet puede convertirse en un canal de exfiltración aunque la entrada esté fuertemente restringida. La propia documentación de Google sobre tokenización con funciones *serverless* advierte que, para determinados diseños PCI DSS, la falta de controles finos de entrada/salida puede exigir controles compensatorios o una plataforma alternativa. \[8\]

Para los Requisitos 3 y 4, la prioridad debe ser minimizar la presencia del PAN. Siempre que el modelo de negocio lo permita, tokenizar antes de que el dato llegue a funciones generales reduce superficie y complejidad. Si una función necesita tratar PAN, deben validarse cifrado en tránsito, almacenamiento temporal, variables de entorno, parámetros, colas de errores, trazas y registros. Un error frecuente es proteger la base de datos y terminar copiando PAN completo en logs, sistemas APM o mensajes de depuración.

# Requisitos 5–8: código, cambios e identidades

| **Dominio PCI DSS** | **Cómo se traduce en serverless** | **Riesgo típico** |
| --- | --- | --- |
| Protección frente a software malicioso (Req. 5) | Evaluar el riesgo real de los componentes; reforzar análisis del código, artefactos y dependencias donde no exista un host administrable. | Asumir que “no hay servidor” significa que no existe riesgo de código malicioso. |
| Desarrollo seguro (Req. 6) | Inventario de software propio y componentes, análisis SAST/SCA, revisión de IaC, gestión de vulnerabilidades y cambios controlados. | Dependencias vulnerables o funciones desplegadas fuera del pipeline aprobado. |
| Acceso por necesidad de negocio (Req. 7) | Roles mínimos por función, políticas específicas por recurso y separación entre despliegue, operación y auditoría. | Roles comodín, permisos heredados o una misma identidad para múltiples funciones. |
| Identificación y autenticación (Req. 8) | Identidades de carga de trabajo de corta duración, MFA para administración y protección reforzada de credenciales humanas. | Claves permanentes en variables, repositorios o secretos compartidos. |

En este modelo, el *pipeline* de desarrollo pasa a ser una pieza crítica del entorno. Si un repositorio, un rol de despliegue o una herramienta de CI/CD puede cambiar una función que procesa pagos, debe analizarse su capacidad de impacto. La revisión de seguridad tiene que cubrir no solo el código fuente, sino también plantillas de infraestructura, dependencias, imágenes o capas reutilizables, parámetros, secretos y el mecanismo de promoción a producción. \[1–2,6\]

# Requisitos 10–11: evidencias, monitorización y pruebas

 Las arquitecturas *serverless* producen mucha telemetría, pero eso no garantiza trazabilidad útil. Para PCI DSS deben correlacionarse, como mínimo, registros de la función, *API Gateway* o equivalente, *control plane* del proveedor, IAM, KMS, secretos, almacenamiento, cambios de configuración y mecanismos de seguridad. Es necesario identificar quién hizo qué, cuándo, desde dónde y sobre qué recurso, y revisar que los errores de aplicación no introduzcan datos de tarjetas en los registros.

La ausencia de un *host* tradicional también cambia el enfoque de vulnerabilidades. Parte del parcheado del sistema operativo pasa al proveedor, mientras que el cliente conserva la responsabilidad sobre código, librerías, dependencias y configuraciones. El inventario de software propio y componentes de terceros de PCI DSS v4.x encaja especialmente bien con *serverless*: una función pequeña puede arrastrar decenas o cientos de paquetes que deben ser conocidos, evaluados y actualizados. \[1,6\]

Las pruebas de seguridad deben diseñarse alrededor de la arquitectura real. Los *endpoints* públicos siguen sujetos a las comprobaciones externas que correspondan; el código y las dependencias necesitan análisis de vulnerabilidades; y el test de intrusión debe recorrer el flujo completo de pago, incluyendo autenticación, APIs, funciones, permisos, movimientos laterales lógicos y accesos a datos. Si la reducción de alcance se apoya en segmentación, deben validarse los controles que crean esa frontera, aunque sean políticas IAM o controles de servicio y no únicamente cortafuegos tradicionales. \[2–3\]

| **Prueba / evidencia** | **Enfoque recomendado en serverless** |
| --- | --- |
| Escaneos externos ASV | Aplicarlos a los activos públicos que entren en los criterios del requisito; no confundir la ausencia de servidores propios con la ausencia de superficie externa. |
| Análisis de vulnerabilidades | Combinar SCA, análisis de artefactos, código, infraestructura como código y configuración cloud. |
| Test de intrusión | Probar el flujo de negocio y las relaciones entre servicios, no solo la URL pública. Incluir abuso de identidades, permisos y eventos. |
| Validación de segmentación | Comprobar que una identidad o recurso fuera del CDE no pueda alcanzar ni impactar los componentes protegidos. |
| Monitorización | Alertar sobre cambios de roles, políticas, secretos, funciones, orígenes de eventos y rutas de datos; correlacionar eventos de aplicación y control plane. |
| Gestión de cambios | Demostrar aprobación, pruebas, segregación, reversión y trazabilidad desde el commit hasta la versión desplegada. |

 

| **Punto de auditoría:** la evidencia debe demostrar el control del entorno lógico. Capturas aisladas de la consola cloud aportan poco si no pueden vincularse con inventarios, configuración como código, repositorios, registros de cambios y evidencias de pruebas reproducibles. |
| --- |

# Terceros, errores comunes y evidencias para auditoría

El proveedor cloud debe gestionarse dentro del programa de terceros: confirmar su estado PCI DSS, verificar que el servicio concreto utilizado está cubierto y conservar la documentación que delimita responsabilidades. El AOC del CSP es evidencia sobre los controles del proveedor; no certifica automáticamente el *workload* del cliente. \[3–5,7\]

Además del CSP, deben analizarse repositorios, CI/CD, observabilidad, librerías y otros servicios que puedan acceder a datos de cuenta o afectar a la seguridad del CDE. En *serverless* estos terceros suelen quedar fuera del diagrama inicial y reaparecen durante la auditoría. \[4\]

| **Error frecuente** | **Consecuencia** |
| --- | --- |
| “Lambda está certificado, por tanto mi solución cumple.” | Se confunde la evaluación del proveedor con la del entorno del cliente. |
| Inventario basado solo en máquinas o IP. | Quedan fuera funciones, eventos, identidades y recursos efímeros. |
| Roles IAM amplios y PAN en logs o colas de error. | Se amplían privilegios y alcance hacia servicios aparentemente auxiliares. |
| Despliegues manuales o separación dev/prod débil. | Se pierde trazabilidad y los entornos pueden seguir impactándose mutuamente. |

# Aproximación práctica al cumplimiento

La forma más eficiente de abordar PCI DSS en serverless es empezar por el flujo de datos y las capacidades de impacto. Desde Internet Security Auditors proponemos: discovery y alcance; matriz de responsabilidades con CSP y terceros; GAP PCI DSS sobre la arquitectura real; Plan de Acción priorizado; apoyo a la implantación y reducción de alcance; pruebas técnicas y revalidación; y auditoría/validación PCI DSS cuando corresponda.

Como QSA, Internet Security Auditors puede apoyar la revisión de arquitectura, data flow, IAM, ciclo de desarrollo, terceros, análisis de riesgos, ASV, test de intrusión y auditoría de cumplimiento. El objetivo es adaptar el estándar al modelo serverless y concentrar el esfuerzo en los controles que realmente permanecen bajo gestión del cliente. \[9\]

Más información: [Adecuación y Certificación PCI DSS.](https://isecauditors.com/implantacion-pci-dss)

# Conclusiones

*Serverless* puede simplificar PCI DSS, pero no lo hace desaparecer. La plataforma traslada al proveedor parte de la infraestructura y operación, mientras aumenta la importancia de alcance, identidad, configuración, desarrollo seguro, observabilidad, terceros y evidencia automatizada.  
La arquitectura adecuada es la que minimiza el PAN, define fronteras demostrables, asigna responsabilidades sin vacíos y permite reconstruir qué código y configuración estaban activos en cada momento. En PCI DSS v4.0.1, esa capacidad de demostrar es tan importante como la tecnología elegida.

Referencias  
[\[1\] PCI Security Standards Council — PCI DSS v4.0.1, estándar vigente y documentación de soporte.](https://www.pcisecuritystandards.org/document_library/?class=pcidss&doc=pci_dss)  
[\[2\] PCI Security Standards Council — PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures (2024).](https://blog.pcisecuritystandards.org/new-information-supplement-pci-dss-scoping-and-segmentation-guidance-for-modern-network-architectures)  
[\[3\] PCI Security Standards Council — PCI DSS Cloud Computing Guidelines v3.0 (2018), suplemento informativo sobre responsabilidad compartida y pruebas en cloud.](https://www.pcisecuritystandards.org/pdfs/PCI_SSC_Cloud_Guidelines_v3.pdf)  
[\[4\] PCI Security Standards Council — FAQ 1580, aplicabilidad de requisitos PCI DSS a proveedores de servicios y responsabilidades compartidas.](https://www.pcisecuritystandards.org/faqs/1580/)  
[\[5\] Amazon Web Services — AWS Services in Scope by Compliance Program: PCI DSS. AWS Lambda figura entre los servicios incluidos; página actualizada el 17/07/2026.](https://aws.amazon.com/compliance/services-in-scope/PCI/)  
[\[6\] Amazon Web Services — Transforming transactions: Streamlining PCI compliance using AWS serverless architecture; y documentación de compliance de AWS Lambda.](https://aws.amazon.com/blogs/security/transforming-transactions-streamlining-pci-compliance-using-aws-serverless-architecture/)  
[\[7\] Google Cloud — Cumplimiento PCI DSS. Cloud Run functions / Cloud Functions se incluyen entre los servicios evaluados, manteniéndose la responsabilidad del cliente sobre sus aplicaciones.](https://cloud.google.com/security/compliance/pci-dss?hl=es)  
[\[8\] Google Cloud Architecture Center — Tokenizing sensitive cardholder data for PCI DSS, ejemplo serverless y consideraciones sobre controles de red.](https://docs.cloud.google.com/architecture/tokenizing-sensitive-cardholder-data-for-pci-dss?hl=es)   
[\[9\] Internet Security Auditors — Adecuación y Certificación PCI DSS: análisis de cumplimiento, implantación, auditoría QSA, ASV y mantenimiento del cumplimiento.](https://isecauditors.com/implantacion-pci-dss)

Fuentes consultadas el 30 de septiembre de 2026. Tablas y síntesis de elaboración propia.

- [Tweet](https://twitter.com/share)

---

![author-image](https://blog.isecauditors.com/hubfs/Logo_isecauditors_contraccion_HP.png)

[Alberto Villar Arévalo](https://blog.isecauditors.com/author/alberto-villar)

PCI SSA, PCI QSA, CISSP, CSSLP, ISO 27001 L.A., CSFPC, SFPC   
 Consultor de Seguridad   
 Depto. de Consultoría

---

[Legal Notice](https://www.isecauditors.com/aviso-legal)

[Policy Privacy](https://www.isecauditors.com/politica-privacidad)

[Cookie Policy](https://www.isecauditors.com/politica-cookies)

<https://www.facebook.com/ISecAuditors> <https://twitter.com/ISecAuditors> <https://www.instagram.com/ISecAuditors/> <https://www.linkedin.com/company/internet-security-auditors/> <https://www.youtube.com/ISecAuditors>

---

Copyright © 2026 - All rights reserved

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Alberto Villar Arévalo",
    "url" : "https://blog.isecauditors.com/author/alberto-villar"
  },
  "dateModified" : "2026-10-23T09:03:31.353Z",
  "datePublished" : "2026-10-23T08:43:43.000Z",
  "headline" : "El reto de PCI DSS en arquitecturas Serverless (Lambda, Cloud Functions)",
  "image" : [ "https://blog.isecauditors.com/hubfs/El%20reto%20de%20PCI%20DSS%20en%20arquitecturas%20Serverless.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://blog.isecauditors.com/el-reto-de-pci-dss-en-arquitecturas-serverless-lambda-cloud-functions",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://blog.isecauditors.com/hubfs/isec_logo.png"
    },
    "name" : "Internet Security Auditors, S.L."
  }
}
```