Datos del titular de la tarjeta (CHD): definición y reglas de PCI DSS

Qué significan realmente los datos del titular de la tarjeta

Los datos del titular de la tarjeta -- normalmente abreviados como CHD -- son el término que PCI DSS usa para la información de tarjeta de pago que puedes almacenar, con ciertas condiciones. Abarca cuatro elementos de datos concretos:

• El número de cuenta principal (PAN) -- el número largo que aparece en el frente de la tarjeta, habitualmente de 16 dígitos.
• El nombre del titular de la tarjeta.
• La fecha de caducidad.
• El código de servicio -- un código de 3 dígitos contenido en la banda magnética que indica al emisor cómo puede usarse la tarjeta.

El PAN es la pieza clave que lo sostiene todo. Si almacenas, procesas o transmites un PAN en cualquier punto de tu negocio, PCI DSS aplica a ese sistema y a todo lo que esté conectado a él. Los otros tres elementos solo se consideran datos del titular cuando se almacenan junto al PAN. Por sí solos, un nombre o una fecha de caducidad no bastan para exigir controles PCI.

CHD frente a SAD: la diferencia que confunde a tanta gente

PCI DSS divide la información de las tarjetas de pago en dos grupos: los datos del titular de la tarjeta y los datos confidenciales de autenticación (SAD). No son lo mismo, y las reglas son muy distintas.

Los SAD incluyen el contenido completo de la banda magnética, el CVV/CVC impreso en el reverso de la tarjeta y el PIN o el bloque de PIN. Bajo PCI DSS v4.0.1, los SAD nunca deben almacenarse una vez autorizada la transacción -- y punto. No hay excepciones del tipo "vamos a guardar el CVV solo para los reembolsos". Puedes retener los SAD durante los pocos segundos que tarda en procesarse una autorización, y luego tienen que desaparecer.

Los CHD son más tolerantes. Puedes almacenar el PAN si lo proteges adecuadamente (cifrado, tokenización, truncamiento o hash -- Requisito 3.5 de PCI DSS v4.0.1). Puedes almacenar el nombre del titular, la caducidad y el código de servicio sin volverlos ilegibles, pero si están en el mismo sistema que un PAN almacenado, quedan dentro del alcance.

Qué exige PCI DSS v4.0.1 para los CHD

PCI DSS v4.0.1 -- la versión actual, con los requisitos de fecha futura de marzo de 2025 ya en vigor -- establece controles concretos para cualquier entorno que toque datos del titular de la tarjeta. Los más importantes:

Requisito 3: proteger los CHD almacenados

El PAN almacenado debe volverse ilegible. Los métodos aceptados son la criptografía fuerte, la tokenización, el truncamiento (mostrando como máximo solo los primeros seis y los últimos cuatro dígitos) o el hash unidireccional con una función con clave. Un PAN en texto plano en una base de datos o en un archivo de registro es un hallazgo a la espera de producirse.

Requisito 4: proteger los CHD en tránsito

Cada vez que un PAN cruza una red abierta o pública -- incluidos internet, las redes inalámbricas y la mayoría de las conexiones con terceros -- necesita criptografía fuerte. TLS 1.2 o superior es la base práctica; SSL y las primeras versiones de TLS llevan años en desuso.

Requisito 9: restringir el acceso físico

Si los CHD residen en papel, memorias USB, cintas de respaldo o discos duros, aplica la seguridad física. Armarios con llave, registros de visitantes, todo.

Requisito 12: política y gobernanza

Necesitas una política documentada de retención y eliminación de datos. El principio: no almacenes CHD que no necesites, y deshazte de lo que sí almacenes en cuanto deje de existir la razón comercial o legal para conservarlo.

Cómo entran los CHD en la mayoría de los centros de contacto

En los pagos telefónicos, los datos del titular de la tarjeta suelen llegar de una de tres maneras, y cada una deja una huella de alcance distinta.

El método tradicional consiste en que el agente teclea el PAN en una pantalla de pago mientras quien llama se lo dicta. Todo lo que hay en ese recorrido -- la línea telefónica, el sistema de grabación de llamadas, la pantalla del agente, la red que hay detrás y, a veces, la propia memoria del agente -- está manejando datos del titular de la tarjeta. Es un entorno amplio dentro del alcance y, por lo general, el más caro de auditar. Hemos profundizado en este compromiso en nuestro artículo sobre por qué la grabación de llamadas tradicional crea problemas de PCI.

El segundo método es un enlace de pago enviado por SMS o correo electrónico, donde quien llama paga en una página web y el agente nunca escucha los datos de la tarjeta. Funciona para algunos flujos, pero falla en otros -- en particular, cualquier pago que necesite completarse durante la propia llamada.

El tercer método es el enmascaramiento DTMF, que es lo que construimos en Paytia. Quien llama marca su número de tarjeta en el teléfono, los tonos se interceptan y se sustituyen antes de llegar al agente o a la grabación, y el PAN se enruta directamente a la pasarela de pago. El agente sigue en la llamada, pero los datos del titular nunca entran en sus sistemas. Eso mantiene al centro de contacto completamente fuera del alcance de los CHD.

Mantener los CHD fuera del alcance

La mejor forma de reducir el coste y el riesgo de PCI es manejar menos datos del titular de la tarjeta -- o mejor aún, ninguno. La reducción del alcance de PCI DSS cuenta con unas cuantas técnicas bien probadas:

• Tokenización -- sustituir el PAN por un token que no tiene valor fuera de la bóveda de tu pasarela de pago. Tus sistemas guardan tokens, no datos de tarjeta.
• P2PE (cifrado punto a punto) -- para transacciones con tarjeta presente, cifrando en el terminal para que el comercio nunca vea el PAN en texto plano.
• Externalización -- recurrir a un proveedor de servicios validado por PCI para gestionar los momentos en que los CHD quedan realmente expuestos.
• Grabación de llamadas con pausa y reanudación -- mejor que nada, pero el consenso de los QSA es que es un control con muchas formas de fallar (el agente olvida pausar, un fallo del software, etc.).

Si consigues diseñar un flujo en el que el PAN nunca aterrice en tu entorno, la mayor parte de PCI DSS no te aplica. Aún necesitarás un SAQ A o similar para documentar ese hecho, pero la carga de la auditoría es una fracción de lo que sería de otro modo.

Errores habituales con los datos del titular de la tarjeta

El patrón que vemos con más frecuencia en las evaluaciones de cumplimiento no es malintencionado -- es retención accidental. Algunos ejemplos:

• PAN en las notas del CRM porque un agente tecleó el número de tarjeta en un campo de texto libre.
• Números de tarjeta completos en las grabaciones de llamadas porque falló la macro de pausa y reanudación.
• Datos de tarjeta en correos electrónicos de clientes reenviados a un buzón compartido.
• Datos de tarjetas de prueba en bases de datos de desarrollo que se respaldan en el mismo lugar que producción.
• Registros de recibos que imprimen el PAN completo en lugar de una versión enmascarada.

Todos estos casos meten dentro del alcance sistemas que el negocio nunca pretendió que lo estuvieran. La solución es en parte técnica (enmascaramiento, redacción, análisis DLP) y en parte de proceso (formación, políticas de retención, análisis periódicos para detectar PAN almacenados).

Por qué esto importa a nivel comercial

El alcance de PCI dispara el coste. Un comercio con un entorno de CHD pequeño y bien segmentado podría completar un SAQ A-EP o un SAQ D en unas pocas semanas y pagar unos pocos miles de libras en honorarios de QSA. Un comercio con datos del titular dispersos entre el CRM, las grabaciones de llamadas, el correo electrónico y los sistemas financieros se enfrenta a un Informe de Cumplimiento completo (ROC), a costes de evaluación de seis cifras y a un riesgo residual de filtración mucho mayor. La diferencia se debe sobre todo a cuántos CHD manejan y a dónde acaban.