Ingeniería PCI DSS para equipos de pagos: construimos los controles, tu evaluador los valida
PCI DSS v4.0.1 aplica a toda entidad que almacena, procesa o transmite datos del titular de la tarjeta o datos sensibles de autenticación, o puede afectar su seguridad. Gran parte de sus 12 requisitos recae sobre ingeniería: alcance y segmentación, criptografía, software seguro, acceso y MFA, logs, escaneos y pruebas. Construimos esos controles. Un Evaluador de Seguridad Calificado (QSA) o tu propia autoevaluación los valida, y tu adquirente y las marcas de pago deciden cuál. No evaluamos ni atestiguamos.
- Tu QSA o adquirente
- Evalúa tu alcance, o recibe tu atestación
- Tu empresa
- Nuestros ingenieros construyen los controles en tu entorno
- Clouditive
Clouditive no evalúa, no atestigua ni firma una Atestación de Cumplimiento
La norma
¿Qué le pide PCI DSS v4.0.1 a la ingeniería?
PCI DSS v4.0.1 (junio de 2024) tiene 12 requisitos principales: controles de seguridad de red, configuraciones seguras, protección de los datos de cuenta almacenados, criptografía en la transmisión, protección contra malware, sistemas y software seguros, acceso según necesidad de conocer, identificación y autenticación, acceso físico, registro y monitoreo, pruebas periódicas y políticas organizacionales. La ingeniería lleva la mayor parte de los Requisitos 1 a 8, 10 y 11. Si debes cumplir o validar, y cómo, lo deciden las marcas de pago y tu adquirente.
Los requisitos que la v4.0 marcó como buena práctica hasta el 31 de marzo de 2025 ahora son obligatorios. PCI DSS v4.0 se retiró el 31 de diciembre de 2024, y la v4.0.1 no agregó ni eliminó requisitos. Esta es la versión que leímos.
Alcance
¿Qué decide cuánto de tu stack está dentro del alcance?
Los requisitos aplican al entorno de datos del titular de la tarjeta, los sistemas que almacenan, procesan o transmiten datos de cuenta, y a los sistemas que pueden afectar su seguridad. Tercerizar las operaciones de pago no te quita la responsabilidad de asegurar que los datos de cuenta estén protegidos. El alcance debe documentarse y confirmarse al menos cada 12 meses y ante un cambio significativo (12.5.2), y se exige un diagrama de flujo de datos preciso (1.2.4).
En ingeniería se gana o se pierde el alcance: qué servicios ven un número de tarjeta, cómo se segmentan las redes, dónde un token reemplaza los datos de la tarjeta. Mapeamos los flujos de datos y proponemos la arquitectura que mantiene los datos de tarjeta en la menor cantidad de sistemas. La decisión de alcance, y si tu segmentación se acepta, son de tu empresa y tu evaluador.
Lo que no afirmamos
¿Qué no afirmamos?
No tenemos ninguna Atestación de Cumplimiento de PCI DSS. No somos un QSA, un Evaluador de Seguridad Interno ni un Proveedor Aprobado de Escaneo (ASV), y no tenemos ningún caso publicado de pagos.
- Nuestro caso fintech es de analítica de inversiones, no de pagos. Los casos enlazados abajo muestran los mismos controles en otros trabajos, y no son una implementación de PCI DSS.
- No completamos tu Informe de Cumplimiento (ROC) ni tu cuestionario de autoevaluación, no firmamos una Atestación de Cumplimiento ni corremos los escaneos externos de vulnerabilidades, que deben venir de un Proveedor Aprobado de Escaneo (11.3.2).
- Las políticas, la decisión de alcance, la gestión de tus proveedores de servicios y la seguridad física de tus sedes quedan con tu empresa.
- No garantizamos el resultado de una evaluación, y no afirmamos ninguna alianza con un procesador de pagos ni con una plataforma de automatización de cumplimiento (GRC).
Los controles
¿Qué requisitos construye el equipo de ingeniería?
Seis grupos de requisitos recaen sobre ingeniería: alcance y segmentación, protección de los datos de cuenta, software seguro y cambios, acceso y MFA, registro, y escaneos con respuesta a incidentes. Para cada uno: lo que pide el requisito, el trabajo de ingeniería y dónde lo hicimos en un caso publicado.
Alcance, segmentación y flujos de datos
Qué le pide a ingeniería¿A dónde van los datos de tarjeta y qué está conectado a ellos?
El Requisito 1 cubre los controles de seguridad de red, el 1.2.4 pide un diagrama de flujo de datos preciso y el 12.5.2 un alcance documentado y confirmado al menos cada 12 meses. La ingeniería: infraestructura definida como código, para que la red sea el diagrama; rutas de denegación por defecto entre segmentos; y un mapa de flujo de datos guardado en el repositorio junto al código que lo cambia.
Dónde lo hicimos
- Toda la plataforma de Google Cloud es OpenTofu, cubierta por 43 pruebas con proveedores simulados que corren sin tocar la cuenta de la nube.Leer el caso de la plataforma de marketing con IA
- El plan de Terraform tiene un freno que detiene los cambios destructivos.Leer el caso de la plataforma de vivienda PropTech
- El servicio está detrás de un balanceador HTTPS global con un WAF de Cloud Armor.Leer el caso de la plataforma de marketing con IA
Lo entrega
- CI/CD e IaC: construcción o rediseñoUSD 4.000 · 2 semanas
Protección de los datos de cuenta
Qué le pide a ingeniería¿Qué datos de cuenta guardas, en qué forma y cómo viajan?
El 3.3.1 pide que los datos sensibles de autenticación no se almacenen tras la autorización, aunque estén cifrados, y el 3.5.1 que el PAN quede ilegible dondequiera que se almacene. El 4.2.1 pide criptografía fuerte y protocolos de seguridad cuando el PAN cruza redes públicas abiertas. La ingeniería: guardar solo lo necesario, tokenizar o truncar el resto, claves gestionadas, TLS en cada ruta y rutas de red privadas hacia los almacenes de datos.
Dónde lo hicimos
- Cloud SQL corre con IP privada, con KMS y Workload Identity.Leer el caso de la plataforma de marketing con IA
- El servicio está detrás de un balanceador HTTPS global con un WAF de Cloud Armor.Leer el caso de la plataforma de marketing con IA
- El borde de Cloudflare usa DNSSEC, CAA y MTA-STS.Leer el caso de la plataforma de vivienda PropTech
Ningún paquete fijo cubre la criptografía y la protección de datos por sí solas. Las definimos en Discovery o con ingenieros por hora.
Software seguro y cambios
Qué le pide a ingeniería¿Cómo se desarrolla de forma segura el software a medida y cómo llega un cambio a producción?
El 6.2.1 y el 6.2.4 piden desarrollo seguro y técnicas que prevengan los ataques de software comunes, el 6.3.2 un inventario del software a medida y de sus componentes de terceros, y el 6.5.1 cambios hechos con motivo, impacto de seguridad, aprobación y pruebas. El 6.4.3 pide que cada script cargado en una página de pago esté autorizado, con integridad verificada e inventariado, y el 11.6.1 detección de cambios y manipulación en las páginas de pago. La ingeniería: un pipeline cuyos controles pueden frenar una versión, inventarios de dependencias y de scripts, y versiones rastreables.
Dónde lo hicimos
- Producción espera una hora bajo observación y debe pasar controles de salud y de tasa de errores. La reversión volviendo a promover se ensayó en desarrollo: 72 segundos hacia atrás, 124 hacia adelante.Leer el caso del pipeline de versiones fintech
- Un tag de versión construye las imágenes, corre las migraciones, despliega por digest de imagen y lee de vuelta el digest que realmente está en producción.Leer el caso de la plataforma de marketing con IA
- Cada versión es una imagen firmada con cosign, desplegada sin tráfico, verificada y recién entonces promovida.Leer el caso del portal de coordinación GovTech
- Un control previo al push verifica secretos, tipos, lint y build antes de que el código salga de la máquina del ingeniero.Leer el caso del portal de coordinación GovTech
Lo entrega
- CI/CD e IaC: construcción o rediseñoUSD 4.000 · 2 semanas
- Fundamentos de automatización de QAUSD 5.000 · 2 semanas
Control de acceso y MFA
Qué le pide a ingeniería¿Quién puede llegar al entorno de datos del titular de la tarjeta y cómo prueba quién es?
El Requisito 7 restringe el acceso según la necesidad de conocer, y el Requisito 8 pide identificación y autenticación, incluido el 8.4.2, MFA para todo acceso sin consola al entorno de datos del titular de la tarjeta. La ingeniería: identidades en tu SSO, MFA, mínimo privilegio, secretos en un almacén gestionado e identidad de workload para los servicios. Nuestros ingenieros usan tus cuentas, y el acceso se revoca cuando termina el contrato.
Dónde lo hicimos
- Los secretos viven en un almacén gestionado, y el control de vulnerabilidades corre en cada solicitud de fusión.Leer el caso del pipeline de versiones fintech
- Cloud SQL corre con IP privada, con KMS y Workload Identity.Leer el caso de la plataforma de marketing con IA
- El envío por Gmail usa delegación de dominio, así que no se guarda ninguna clave de correo.Leer el caso del portal de coordinación GovTech
- El stack de observabilidad se lee en Grafana con inicio de sesión único.Leer el caso de ingeniería de plataforma en transporte
Ningún paquete fijo cubre el control de acceso por sí solo. Lo definimos en Discovery o con ingenieros por hora.
Registro y monitoreo
Qué le pide a ingeniería¿Los logs de auditoría están activos en cada componente, se guardan el tiempo suficiente y alguien los vigila?
El 10.2.1 pide que los logs de auditoría estén habilitados y activos en todos los componentes y datos del titular, y el 10.5.1 que el historial se conserve al menos 12 meses con los últimos tres meses disponibles de inmediato para análisis. La ingeniería: logs de cada componente en un solo lugar, diseñados para que los números de tarjeta nunca terminen en una línea de log, alertas probadas hasta que disparan y un runbook.
Dónde lo hicimos
- De cero alertas en producción a 275 reglas de alerta, cada una probada hasta que disparó.Leer el caso del pipeline de versiones fintech
- Colectores de OpenTelemetry en cada clúster envían a Mimir, Loki, Tempo y Pyroscope centrales. Los paneles pasaron de 18 a 135.Leer el caso de ingeniería de plataforma en transporte
- Las trazas de OpenTelemetry van a Google Cloud y 18 políticas de alerta vigilan el servicio.Leer el caso de la plataforma de marketing con IA
Lo entrega
- Fundamentos de SRE y observabilidadUSD 5.000 · 2 semanas
Escaneos, pruebas y respuesta a incidentes
Qué le pide a ingeniería¿Con qué frecuencia escaneas y pruebas, y cuál es el plan cuando algo sale mal?
El 11.3.1 pide escaneos internos de vulnerabilidades al menos cada tres meses con reescaneos hasta resolver los hallazgos críticos y de alto riesgo, el 11.4.1 una metodología de pruebas de penetración definida, y el 12.10.1 un plan de respuesta a incidentes que incluya avisar a las marcas de pago y a los adquirentes y cubra recuperación y backup de datos. La ingeniería: escaneos en el pipeline en cada cambio con excepciones que vencen, y un runbook que dice quién decide y a quién se avisa.
Dónde lo hicimos
- Un control de vulnerabilidades orientado a SOC 2 corre en cada solicitud de fusión (merge request), con excepciones que vencen. No es una certificación.Leer el caso del pipeline de versiones fintech
- Desde febrero de 2026 un workflow compartido corre escaneos de dependencias, secretos, CodeQL y contenedores. El endurecimiento de la cadena de suministro de CI está en curso.Leer el caso de ingeniería de plataforma en transporte
- Los backups son cifrados y programados, y el ensayo de restauración recupera los datos en 13 segundos.Leer el caso de la plataforma de RPG online
Lo entrega
- CI/CD e IaC: construcción o rediseñoUSD 4.000 · 2 semanas
Las pruebas de penetración y los escaneos externos trimestrales los hacen terceros independientes y calificados. Nosotros construimos los escaneos que corren en tu pipeline.
Cómo entregamos
¿Cómo lo entregan nuestros paquetes e ingenieros?
Empieza con un paquete de precio fijo, o contrata ingenieros por hora. El paquete de CI/CD e IaC construye el pipeline y la infraestructura como código. Los Fundamentos de SRE y observabilidad conectan el monitoreo. Los Fundamentos de automatización de QA ponen pruebas en tu CI. Discovery convierte tu diagrama de alcance, los hallazgos de tu evaluador o las brechas de tu autoevaluación en un roadmap con backlog.
Pipeline e infraestructura como código
Una construcción o rediseño de 2 semanas de tus pipelines de CI/CD y de tu infraestructura como código. Los controles que entran al pipeline, como un escaneo de vulnerabilidades, se acuerdan en el SOW.
Lo entrega
- CI/CD e IaC: construcción o rediseñoUSD 4.000 · 2 semanas
Registro y monitoreo
Métricas, logs y trazas conectados, 3 SLOs definidos, alertas probadas hasta que disparan y un runbook.
Lo entrega
- Fundamentos de SRE y observabilidadUSD 5.000 · 2 semanas
Pruebas en cada cambio
Una suite de Playwright para tus 5 flujos críticos, corriendo en tu CI, con verificaciones de accesibilidad.
Lo entrega
- Fundamentos de automatización de QAUSD 5.000 · 2 semanas
De la lista de requisitos a un backlog
Discovery entiende tu producto y su configuración de punta a punta y entrega un roadmap con backlog, roles, cambios críticos y necesidades. Trae tu diagrama de alcance, los hallazgos del evaluador o las brechas de tu autoevaluación y los convertimos en trabajo de ingeniería.
Lo entrega
- DiscoveryUSD 7.000 · 1 a 4 semanas
Ingenieros por hora
Para el trabajo que sigue después de un paquete: Senior USD 45–50 la hora, Lead o Arquitecto USD 55–60, con mínimo de 6 meses, facturado por hora trabajada. Tú entrevistas al ingeniero que hará el trabajo.
Fuentes
¿Qué textos leímos?
Textos primarios, leídos el 2026-10-09.
- Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1, junio de 2024, PCI Security Standards Council. Secciones 2 y 11 a 12, Requisitos 1 a 12.
- PCI Security Standards Council, "Just Published: PCI DSS v4.0.1", sobre el retiro de la v4.0 y la fecha del 31 de marzo de 2025.
Preguntas frecuentes
¿Clouditive cumple PCI DSS o está certificada?
No. No tenemos ninguna Atestación de Cumplimiento de PCI DSS y no afirmamos ninguna para ningún cliente. La norma pide cumplir a las entidades que manejan datos de tarjetas, y las marcas de pago y los adquirentes deciden cómo se valida el cumplimiento.
¿Pueden reemplazar a nuestro QSA?
No. Un QSA es una empresa calificada por el PCI Security Standards Council para evaluar y redactar el Informe de Cumplimiento. Construimos los controles de ingeniería que esa evaluación prueba, y no somos un QSA.
¿Tienen un cliente de pagos?
No tenemos ningún caso publicado de pagos. Nuestro caso fintech es de analítica de inversiones. Los casos enlazados en esta página muestran los mismos controles en trabajos de analítica fintech, govtech, proptech, IA y transporte.
¿Pueden reducir nuestro alcance de PCI?
Diseñamos la arquitectura para que los datos de tarjeta vivan en la menor cantidad de sistemas, y documentamos los flujos de datos. Si el resultado se acepta lo decide tu evaluador. Tercerizar las operaciones de pago no te quita la responsabilidad de asegurar que los datos de cuenta estén protegidos.
¿A qué versión de PCI DSS trabajan?
A la 4.0.1, publicada en junio de 2024. PCI DSS v4.0 se retiró el 31 de diciembre de 2024, y los requisitos que eran buena práctica hasta el 31 de marzo de 2025 ahora son obligatorios.
¿Cuánto tarda en quedar listo?
Depende de tu alcance y de lo que ya tengas, y no damos ninguna garantía sobre una evaluación. Un paquete de 2 semanas construye un área, como el pipeline de CI/CD y la infraestructura como código, y Discovery, de 1 a 4 semanas, convierte el resto en un roadmap.
¿Cómo se relaciona esto con SOC 2 y los otros marcos?
La ingeniería se superpone mucho: versiones con controles, accesos demostrables, alertas probadas y recuperación ensayada sirven a varios marcos a la vez. La página de ingeniería de cumplimiento muestra qué cláusula de cada marco pide qué control.
¿Cómo acceden sus ingenieros a nuestros sistemas?
A través de tus propias cuentas e identidades, con tu SSO, tu MFA y acceso de mínimo privilegio, que se revoca cuando termina el contrato. Todo ingeniero pasa una verificación de antecedentes antes de ser asignado.
¿Quién hace el trabajo?
Mat Caniglia lidera cada proyecto de punta a punta, y los ingenieros están en LATAM y comparten tu jornada. Presentamos candidatos en 1 semana, y tú entrevistas al ingeniero que hará el trabajo.
¿Qué necesitas resolver?
Respondemos cada pedido en 1 día hábil. Firmamos un NDA antes de la llamada si lo pides.