Servicios05 / 07

El cumplimiento como restricción de diseño

El cumplimiento se sufre cuando llega al final. Un equipo construye durante un año, aparece la auditoría y descubre que el número de tarjeta se guarda en texto plano en una tabla de logs. Rehacer eso cuesta diez veces más que haberlo evitado, y el coste no es solo técnico: es la fecha de salida que se corre dos trimestres.

Tratado como restricción de diseño, el mismo requisito produce un sistema mejor. Si nunca almacenas el PAN, no tienes que protegerlo ni justificarlo ante nadie. Si el registro de auditoría es inmutable por construcción, la evidencia para el auditor es una consulta y no un proyecto.

Trabajo PCI DSS y SOC 2 en sistemas de pago, y privacidad —GDPR en Europa, habeas data en Colombia— en cualquier sistema que toque datos personales. El enfoque es el mismo: entender qué exige la norma en términos de comportamiento del sistema, y traducirlo a controles que se verifican solos en el pipeline.

Normas
PCI DSS · SOC 2
Privacidad
GDPR
Incidentes
−75%
Formato
Programa
Certificaciones
ISO 27001
PCI DSS
Escribirme
Alcance

¿Qué involucra?

  1. 01Cumplimiento PCI DSS
  2. 02Implementación GDPR
  3. 03Auditorías de seguridad
  4. 04Protección de datos sensibles
  5. 05Gestión de identidades y accesos
Método

¿Cómo se aborda?

  1. Paso 01

    Mapa de datos y alcance

    Dónde entra cada dato sensible, por dónde pasa y dónde se queda. El primer resultado suele ser una reducción de alcance: la mayor parte del sistema deja de estar sujeta a la norma en cuanto el dato deja de atravesarla.

  2. Paso 02

    Modelado de amenazas

    STRIDE sobre los flujos que importan, con la pregunta concreta de qué gana un atacante en cada punto. Produce una lista de controles justificados, no una checklist copiada de un PDF.

  3. Paso 03

    Controles verificados en el pipeline

    SAST, análisis de dependencias, detección de secretos y política como código en cada commit. Un control que depende de que alguien se acuerde no es un control; uno que rompe la build sí lo es.

  4. Paso 04

    Evidencia continua

    Registro de auditoría inmutable, rotación de secretos automatizada y accesos con mínimo privilegio revisados periódicamente. Cuando llega la auditoría, la evidencia ya existe: no hay que fabricarla en tres semanas de pánico.

Principio

El dato que no guardas no lo tienes que proteger

La forma más barata de cumplir una norma es quedar fuera de su alcance. Si el número de tarjeta nunca toca tu infraestructura porque se tokeniza en el borde, no hay que cifrarlo, ni rotarle llaves, ni justificar su almacenamiento ante un auditor. El control más fuerte es el dato ausente.

Ese razonamiento es el que aplico primero, y por eso el entregable inicial es un mapa de datos y no una lista de controles. El resultado habitual sorprende: la mayor parte del sistema deja de estar sujeta a la norma en cuanto el dato deja de atravesarla, y el trabajo se reduce antes de escribir una línea de código.

Lo mismo llevé al código abierto. zefer-cli cifra con AES-256-GCM en el cliente y sube solo el resultado: el servidor no puede leer lo que almacena aunque quiera. Es la misma idea —eliminar la confianza en lugar de gestionarla— aplicada a una herramienta que cualquiera puede instalar y auditar.

  • Mapa de datos primero: qué entra, por dónde pasa, dónde se queda
  • Reducción de alcance antes que adición de controles
  • Tokenización en el borde y minimización por defecto
  • Controles que rompen la build, no que dependen de que alguien recuerde
  • Evidencia continua: cuando llega la auditoría, ya existe
Evidencia

¿Dónde lo he hecho?

Wompi (Grupo Bancolombia)
Desarrollo bajo PCI DSS en la pasarela y sus integraciones bancarias
PCI DSS
Yummy Inc. · Pagos en producción
Medios de pago y datos de pagadores bajo requisitos de cumplimiento continuo
2M tx/día
Yummy Inc. · Certificaciones
Certificado en ISO 27001 y PCI DSS en el contexto de la operación de pagos
ISO 27001
zefer · Código abierto
Cifrado AES-256-GCM en el cliente con Web Crypto API, app web y CLI: el servidor nunca ve los datos
AES-256-GCM

Las cifras vienen de sistemas en producción. La trayectoria completa está en Sobre mí.

Ejecución

Prácticas y entregables

Prácticas

  • Modelado de amenazas STRIDE
  • Zero trust
  • Mínimo privilegio
  • Policy as code
  • SAST y SCA en CI
  • Rotación de secretos
  • Registro de auditoría inmutable

Entregables

  • Mapa de datos y reducción de alcance
  • Modelo de amenazas por flujo
  • Matriz de controles con su evidencia
  • Controles automatizados en el pipeline
  • Plan de respuesta a incidentes ensayado

Stack

  • Azure
  • AWS
  • Terraform
  • OpenTelemetry
  • Vault
Preguntas

Lo que suelen preguntarme

¿Emites la certificación?
No, eso lo hace un auditor acreditado y es correcto que sea así. Mi trabajo es que cuando llegue, el sistema y la evidencia estén listos, y acompañar el proceso desde el lado técnico.
¿Por dónde se empieza si no hay nada hecho?
Por el mapa de datos. Casi siempre revela que el alcance real es mucho menor del que se asumía, y eso reduce el trabajo antes de escribir una sola línea de código.
¿Esto frena la velocidad del equipo?
Al principio sí, unas semanas. Después la acelera, porque los controles automatizados sustituyen revisiones manuales y las preguntas del auditor dejan de interrumpir el desarrollo.
¿Cubres habeas data y no solo GDPR?
Sí. En Colombia y buena parte de LATAM el marco local es el que aplica; los principios de minimización y consentimiento se implementan igual, cambian las obligaciones formales.