¿Qué son los Sensitive Authentication Data?
Los Sensitive Authentication Data (SAD) son una categoría de información de tarjeta de pago que se usa para autenticar transacciones pero que nunca debe almacenarse después de la autorización. Incluyen el código de seguridad de la tarjeta (CVV/CVC), el PIN o PIN block y los datos completos de la banda magnética o del chip. PCI DSS prohíbe estrictamente la retención de SAD después de que se haya autorizado una transacción.
Qué son los Sensitive Authentication Data
Los sensitive authentication data (SAD) son el subconjunto de información de la tarjeta de pago que se utiliza para autenticar una transacción pero que nunca debe almacenarse después de la autorización. Incluyen tres elementos concretos: los datos completos de banda magnética (o su equivalente en el chip), el código de seguridad de la tarjeta (CVV/CVC/CV2) y el PIN o PIN block.
Mientras que PCI DSS permite a las organizaciones almacenar ciertos datos del titular de la tarjeta (como el número de tarjeta y la fecha de caducidad) bajo condiciones estrictas, los sensitive authentication data se tratan de forma diferente. Una vez que una transacción ha sido autorizada, los SAD deben eliminarse de forma segura. Sin excepciones. Sin excusas. Aunque los cifres, aunque creas que los puedes necesitar después. Las reglas son absolutas.
Los tres tipos de SAD
Datos de pista completa
La banda magnética en el reverso de una tarjeta de pago contiene dos o tres pistas de datos. Estos datos incluyen el número de tarjeta, la fecha de caducidad, el código de servicio y otra información codificada por el emisor de la tarjeta. El chip de una tarjeta moderna contiene datos equivalentes. Los datos completos de pista se usan durante las transacciones presenciales para verificar que la tarjeta física es genuina.
Si los datos completos de pista se capturan y almacenan, un delincuente podría crear una tarjeta falsificada con banda magnética funcional. Por eso PCI DSS prohíbe su almacenamiento después de la autorización en cualquier circunstancia.
Códigos de seguridad de la tarjeta (CVV/CVC/CV2)
El código de tres dígitos impreso en el reverso de la mayoría de las tarjetas (o cuatro dígitos en el anverso de las tarjetas American Express) está diseñado específicamente para transacciones sin presencia de tarjeta. Cuando un cliente facilita este código durante un pago telefónico u online, demuestra que tiene acceso físico a la tarjeta, o al menos acceso a un lado de ella que no se puede leer electrónicamente.
Almacenar el código de seguridad después de la autorización es una de las violaciones más comunes de PCI DSS, y una de las más peligrosas. Si se vulnera la base de datos de un comercio y contiene números de tarjeta junto con sus códigos de seguridad, los delincuentes tienen todo lo que necesitan para hacer compras fraudulentas.
PIN y PIN block
El Número de Identificación Personal (PIN) es el código secreto que el titular de la tarjeta introduce en un terminal para autorizar una transacción con chip y PIN. El PIN block es la forma cifrada del PIN cuando viaja por la red de pagos. Almacenar el PIN o el PIN block después de la autorización está estrictamente prohibido porque permitiría a los delincuentes hacer transacciones presenciales fraudulentas y retiradas en cajeros automáticos.
Por qué los SAD nunca deben almacenarse
La razón por la que PCI DSS trata a los SAD con tanto rigor se reduce al daño que se podría hacer si quedaran comprometidos. Los datos normales del titular de la tarjeta —el número de tarjeta, el nombre del titular, la fecha de caducidad y el código de servicio— pueden usarse para fraude, pero hay límites. Un número de tarjeta sin el código de seguridad es menos útil para el fraude online. Un número de tarjeta sin los datos de pista no se puede usar para crear una tarjeta falsificada.
Los SAD rellenan estas brechas. Si un delincuente tiene el número de tarjeta y el código de seguridad, puede comprar online. Si tiene los datos de pista, puede clonar la tarjeta. Si tiene el PIN, puede vaciar la cuenta en un cajero. Por eso el sector de las tarjetas de pago traza una línea dura: una vez que la transacción se autoriza y los datos han cumplido su propósito de autenticación, hay que destruirlos.
SAD frente a datos del titular de la tarjeta
Es importante entender la distinción entre sensitive authentication data y datos del titular de la tarjeta, porque PCI DSS los trata de forma distinta.
- Datos del titular de la tarjeta (PAN, nombre del titular, fecha de caducidad, código de servicio) pueden almacenarse si se protegen según los requisitos de PCI DSS: cifrados, con acceso controlado y con una justificación de negocio documentada.
- Sensitive authentication data (datos completos de pista, códigos de seguridad, PINs) nunca deben almacenarse después de la autorización, independientemente de cómo se protejan. No hay justificación de negocio que lo haga aceptable.
Esta distinción importa porque muchas organizaciones no se dan cuenta de que están almacenando SAD. Las grabaciones de llamadas que capturan a los clientes dictando su CVV están almacenando un código de seguridad. Los formularios de pago que guardan el campo CVV en una base de datos están almacenando un código de seguridad. Incluso los archivos de log que capturan las solicitudes de transacción al completo pueden contener SAD sin que nadie lo pretenda.
SAD y pagos telefónicos
Los pagos telefónicos crean riesgos particulares en torno a los sensitive authentication data, sobre todo el código de seguridad de la tarjeta. Durante un pago telefónico típico, el cliente dicta su número de tarjeta, fecha de caducidad y CVV a un agente. Si la llamada se graba —como ocurre con la mayoría de las llamadas de centros de contacto— la grabación contiene el CVV en el audio.
Eso significa que la organización está almacenando sensitive authentication data, lo que es una violación directa del Requisito 3.2 de PCI DSS. Y no es solo la grabación en sí: los archivos de audio están en servidores, se hacen copias de seguridad, pueden ser accesibles a los equipos de monitorización de calidad y podrían conservarse durante meses o años.
Esta es una de las razones más convincentes para que los negocios adopten enmascaramiento DTMF para los pagos telefónicos. Cuando los clientes introducen los datos de su tarjeta en el teclado del teléfono y los tonos se enmascaran antes de llegar al agente, ningún sensitive authentication data entra en el audio de la llamada. No hay nada en la grabación que viole la prohibición de almacenamiento, y nada que un atacante pueda extraer.
Errores comunes con los SAD
Incluso las organizaciones que conocen las reglas a veces cometen errores con los sensitive authentication data. Estos son los más comunes.
- Grabaciones de llamadas: grabar llamadas en las que los clientes dictan su CVV sin tener implantada ninguna tecnología de enmascaramiento o redacción.
- Logs de aplicación: aplicaciones de pago que escriben los detalles de la transacción, incluidos los códigos de seguridad, en archivos de log para fines de depuración.
- Correo y chat: clientes que envían los datos de la tarjeta incluido el CVV por correo o chat en directo, que luego se quedan en buzones y logs de chat indefinidamente.
- Formularios en papel: hojas de pedido que incluyen un campo para el CVV, que luego se archivan, se escanean o se guardan sin procedimientos seguros de destrucción.
- Sistemas de backup: aunque el sistema principal purgue correctamente los SAD, las copias de seguridad pueden retener los datos durante semanas, meses o años.
Pasos prácticos para proteger los SAD
Proteger los sensitive authentication data consiste fundamentalmente en evitar que se capturen y se almacenen para empezar. Una vez que existen en tus sistemas, tienes un problema que solucionar. El enfoque más eficaz es mantenerlos fuera por completo.
- Usa enmascaramiento DTMF para los pagos telefónicos para que los códigos de seguridad de las tarjetas nunca entren en el audio de la llamada ni en las grabaciones.
- Asegúrate de que las aplicaciones de pago están configuradas para no registrar en logs los códigos de seguridad ni los datos completos de pista.
- Prohíbe a los clientes enviar datos de tarjeta por correo o chat, y forma al personal para reconocer y rechazar esas comunicaciones.
- Si se usan formularios en papel, elimina el campo CVV por completo: solo se necesita para la propia transacción y no hay que apuntarlo.
- Revisa las políticas de backup y retención para asegurarte de que los SAD no se están conservando de ninguna forma.
La plataforma de Paytia está diseñada para que los sensitive authentication data nunca entren en tu entorno. Cuando un cliente teclea los datos de su tarjeta durante un pago telefónico, los datos se capturan y se enrutan directamente al procesador de pagos a través de la infraestructura de Paytia certificada en PCI DSS Nivel 1.
Tus agentes nunca oyen, ven ni tienen acceso al código de seguridad de la tarjeta, y no se almacena ningún SAD en ningún punto de tus sistemas. Esto elimina por completo la categoría más seria de riesgo de PCI DSS de tu centro de contacto.
Preguntas frecuentes
¿Puedo almacenar el código CVV si lo cifro?
No. PCI DSS prohíbe el almacenamiento de sensitive authentication data después de la autorización independientemente del método de protección usado. Esto incluye el cifrado, el hashing o cualquier otra técnica. El código CVV debe descartarse en cuanto se autoriza la transacción.
¿Cuál es la diferencia entre sensitive authentication data y datos del titular de la tarjeta?
Los datos del titular de la tarjeta (como el número de tarjeta, el nombre del titular y la fecha de caducidad) pueden almacenarse si se protegen correctamente con cifrado y controles de acceso. Los sensitive authentication data (códigos CVV, PINs y datos completos de pista) nunca deben almacenarse después de la autorización bajo ninguna circunstancia. Ambos están cubiertos por PCI DSS pero los SAD tienen reglas más estrictas.
¿Qué pasa si descubren que mi negocio está almacenando sensitive authentication data?
Almacenar SAD después de la autorización es una de las violaciones más graves de PCI DSS. Puede resultar en multas significativas de las marcas de tarjetas, investigaciones forenses obligatorias y la posible retirada de tu capacidad de aceptar pagos con tarjeta. Si se produce una brecha como consecuencia, la organización también puede enfrentarse a responsabilidad legal por las pérdidas de fraude.
Ready to take secure payments?
Book a demo with our team. We'll show you DTMF masking live, talk through PCI DSS scope reduction, and put together pricing based on your call volume.
Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia