A diferencia de otros estándares de seguridad, el estándar PCI DSS permite cierta flexibilidad en la implementación de sus controles. Si existen restricciones técnicas o administrativas que impiden implementar un control «tal cual» según se pide en el estándar, se puede establecer una medida alternativa para la gestión del riesgo identificado, empleando un enfoque alternativo. Estos controles «alternativos» se denominan «Controles Compensatorios». Aquí te explicamos qué son y cuándo se utilizan.
El estándar PCI DSS define una serie de controles físicos, lógicos y administrativos para la protección de los datos de tarjetas de pago que se transmiten, se procesan y/o se almacenan. La mayoría de las veces estos controles se pueden implementar sin mayores traumatismos dentro de la organización, pero otras veces (ya sea por limitantes técnicas o administrativas) es muy difícil proceder con el despliegue de un control de acuerdo con las indicaciones del estándar. Por ejemplo:
- Una organización tiene en su infraestructura de comunicaciones una gran cantidad de equipos activos de red con un firmware que no permite cifrar la transferencia de datos de autenticación administrativa, por lo que se sigue empleando un protocolo inseguro (telnet). Sin embargo, el solo hecho de realizar un cambio en todo este parque de equipos implica una inversión económica bastante elevada que supera el presupuesto técnico asignado.
- Una empresa tiene una aplicación crítica para su negocio que solo puede ejecutarse en un sistema operativo ya obsoleto y sin soporte del fabricante. Esta aplicación no puede migrarse a corto plazo, debido a que cualquier cambio puede afectar la operación.
- Una empresa cuenta con una arquitectura centralizada cliente/servidor, en la cual se tiene un servidor mainframe que desempeña tareas para diferentes áreas y procesa y almacena información con distintos niveles de confidencialidad, por lo que “aislar” este entorno no es viable a corto plazo.
- El software proporcionado por un fabricante en particular no cumple con los controles de gestión de contraseñas de PCI DSS (longitud, complejidad, historial, etc.), y las únicas alternativas disponibles no son compatibles con el sistema operativo en el que está instalado dicho software.
Como se puede concluir de los ejemplos anteriores:
- En algunas ocasiones, el coste de implementación de un control de seguridad puede superar el del sistema afectado, lo cual no se compensa desde el punto de vista económico.
- El despliegue de un control de seguridad puede requerir más tiempo del necesario para desmantelar la plataforma afectada.
- A veces no existen opciones viables para reemplazar en el corto plazo un sistema crítico, pero clasificado como obsoleto.
Frente a esto, ¿cómo proceder en estos casos? Aquí es cuando entran en escena los controles compensatorios.
¿Qué es un control compensatorio?
Cuando se detectan estas limitaciones técnicas o administrativas, puede existir un potencial incumplimiento de uno o varios requisitos del estándar PCI DSS. No obstante, es posible cumplir con el estándar si se cuenta con un argumento justificado y documentado que describa la limitante técnica o administrativa (a ser validado por un QSA) haciendo uso de controles compensatorios (o “controles de compensación” como se traduce en el estándar PCI DSS en español). Un control compensatorio es un control que, aunque no esté descrito explícitamente en el estándar, permite proporcionar un nivel de seguridad similar (o superior) al del control original y debe emplearse en circunstancias excepcionales. Está descrito en el Anexo B y cuenta con una hoja de trabajo de reporte (Anexo C) en el documento del estándar (versión 4).
Los controles compensatorios – para poder ser aceptados como tal – deben cumplir con los siguientes criterios:
- Cumplir con el propósito y el rigor del requisito original de PCI DSS.
- Proporcionar un nivel de defensa similar al requisito original de PCI DSS, de manera que el control compensatorio compense el riesgo para el que se diseñó dicho requisito.
- Ir más allá («above and beyond») del simple cumplimiento del requisito (El simple cumplimiento de otros requisitos de PCI DSS no constituye un control de compensación).
- Gestionar el riesgo adicional impuesto por no alinearse al requisito de PCI DSS afectado.
- Abordar el requisito desde los puntos de vista actual y futuro. Un control compensatorio no puede aplicarse a una tarea que no se haya ejecutado en el pasado.
Para poder utilizar un control compensatorio es importante tener presentes tres elementos claves:
- Un control de PCI DSS no puede considerarse un control compensatorio si ya fue requisito del elemento en revisión.
- Un control de PCI DSS se puede considerar control compensatorio si se requiere para otro requerimiento pero no es requisito para el elemento en revisión.
- Los controles existentes de PCI DSS pueden combinarse con nuevos controles para convertirse en un control compensatorio.

Hoja de trabajo de controles compensatorios
Hay otra restricción muy importante que, aunque no está estipulada explícitamente en el estándar PCI DSS, es una característica imprescindible de los controles compensatorios: su carácter temporal. Un control compensatorio debería ser temporal y excepcional. Los controles compensatorios no deben ser indefinidos, sino tratados como controles temporales y excepcionales, orientados a la gestión específica de un riesgo particular en un horizonte temporal definido. El objetivo final de la entidad es alinearse cuanto antes con el control original, obteniendo un periodo de gracia mediante controles compensatorios. No obstante, el control compensatorio debe evaluarse anualmente para confirmar que sigue siendo efectivo y necesario.
Los controles compensatorios serán válidos siempre y cuando la restricción técnica y/o administrativa que los originó siga vigente. Este criterio definirá su temporalidad (gracias a Fortiá Bofill por la aclaración).
Ejemplos de controles compensatorios
A continuación se describe una serie de controles que pueden emplearse como compensatorios por una entidad (ya sean por sí solos o combinados entre sí o con otros controles del estándar), en función de sus necesidades y tras un análisis de coste/beneficio. Se hace hincapié en la necesidad de respaldar estas decisiones con el criterio de un QSA y se presentan únicamente a modo de ejemplo. La efectividad de un control compensatorio depende de diferentes variables (cómo se implementó el control, el entorno afectado, los controles adicionales a nivel perimetral, etc.), por lo que el control compensatorio utilizado en un entorno puede no serlo en otro.
- Uso de herramientas de DLP (Data Loss Prevention) que, aunque no están exigidas explícitamente en PCI DSS, podrían emplearse en escenarios en los que exista riesgo de exfiltración de datos sensibles debido a la ausencia de controles de seguridad en los propios datos durante su almacenamiento o transmisión.
- Uso de controles robustos de acceso a la red (Network Access Control, NAC) que identifiquen los dispositivos confiables y «aislen» aquellos que no cumplan con las políticas de seguridad corporativas.
- Uso de controles de ejecución de programas basados en listas blancas (Whitelist). Este tipo de listas se usa para permitir la ejecución de determinadas aplicaciones y bloquear de forma obligatoria todas las demás. Es un enfoque complementario a las soluciones antimalware, ya que éstas últimas suelen emplear listas negras (firmas de software malicioso que se deben bloquear).
- Uso de controles de filtrado de URL para limitar la navegación de los usuarios y permitir únicamente el acceso a sitios web autorizados.
- Uso de grabación de sesiones de usuario (pantalla) con tecnologías como Screen Session Recording or User Activity Monitoring
- Uso de herramientas que permitan la elevación de privilegios generando registros de eventos de la sesión (como “SU” y “SUDO” en Unix)
- Uso de túneles VPN IPSEC/TLS/SSH dentro del CDE. El cifrado a nivel de canal solo se requiere al transmitir datos de tarjetas en redes públicas abiertas o credenciales administrativas.
Entre otros.
Diferencia entre un control compensatorio y el enfoque personalizado
La versión 4.0 de PCI DSS introdujo el concepto de Enfoque Personalizado (Customized Approach). Mientras que en el enfoque tradicional (ahora denominado “Enfoque Definido” – Defined Approach) la entidad implementaba los controles técnicos establecidos tal y como aparecían en el estándar, en el Enfoque Personalizado la entidad puede seleccionar el control que considere más adecuado a su entorno para gestionar el riesgo, lo que ofrece mayor flexibilidad y adaptación a soluciones emergentes.

Descripción del Enfoque Definido y del Enfoque Personalizado en PCI DSS v4.0
Como puede observarse, un control compensatorio y un enfoque personalizado permiten aplicar controles alternativos al control original de PCI DSS. Sin embargo, la principal diferencia entre estos dos conceptos radica en la presencia de una restricción. Mientras que el uso de un control compensatorio depende exclusivamente de la existencia de una restricción técnica o administrativa, en la aplicación del enfoque personalizado tales restricciones no son necesarias, sino que se basan en la madurez de la entidad en la implementación de controles de seguridad.

Finalmente, es importante señalar que no todos los estándares del PCI SSC permiten el uso de controles compensatorios. Los estándares PCI P2PE, PCI TSP y PCI Card Production (PCI CP) exigen la implementación de sus controles sin excepciones.
Suplemento informativo de controles compensatorios y enfoque personalizado
En junio de 2026, el PCI SSC publicó la primera versión del documento «Information Supplement: PCI DSS v4.x: Guidance for Compensating Controls and the
Customized Approach». El objetivo de este documento es proveer una guía práctica para apoyar la definición, implementación y uso de los controles compensatorios y del enfoque personalizado (customized approach), en el que se aclaran algunos puntos en donde anteriormente había opiniones dispares:
- Algunos controles del estándar PCI DSS no permiten el uso de un enfoque personalizado. En estos casos, esta restricción se incluye en la descripción del control afectado:

- Se recomienda el enfoque personalizado para entidades con madurez demostrable en la gestión de riesgos, que cuenten con un departamento de gestión de riesgos o un enfoque global de gestión de riesgos.
- El uso del enfoque personalizado no está contemplado en los cuestionarios de autoevaluación (Self-Assessment Questionnaires – SAQ), a menos que la entidad afectada rellene un Report on Compliance (RoC).
- La principal diferencia entre un control compensatorio y el enfoque personalizado radica en la presencia de una limitación técnica o administrativa. Si bien este tipo de restricciones debe existir para establecer un control compensatorio, no es necesario recurrir a ellas en un enfoque personalizado, en el que la entidad opta por gestionar el requerimiento de manera distinta de la establecida por el estándar.
- Un control compensatorio y un enfoque personalizado pueden emplearse conjuntamente para satisfacer un requerimiento específico.
- Un único control compensatorio puede usarse para cubrir múltiples requerimientos. No obstante, en estos casos se debe diligenciar una hoja de trabajo de controles compensatorios para cada uno de los requerimientos afectados.
- Un control compensatorio o un requerimiento cubierto mediante el enfoque personalizado puede ser inválido si el asesor confirma que no está debidamente documentado ni justificado.
- Un asesor QSA que esté involucrado en el diseño, el desarrollo y/o la implementación de controles de seguridad no puede evaluar su cumplimiento. En todo momento, es imprescindible confirmar que no existe conflicto de interés, tal y como se establece en la FAQ 1562: Is a QSA Employee that designs, develops, or implements specific controls for a customer also permitted to assess those same controls?.
Sin embargo, la sección más relevante de este documento son los ejemplos de controles compensatorios y enfoques personalizados, descritos en el Appendix: Examples of Completed Compensating Control and Customized Approach Templates. A lo largo de esta sección se presentan diferentes plantillas con ejemplos de cómo rellenar los anexos de controles compensatorios y enfoques personalizados, así como ejemplos de Targeted Risk Analysis (TRA) cuando se usa el enfoque personalizado.