PCI DSS 4.0 y Regulacion Sectorial: Pagos, Salud y Infraestructuras Criticas

Regulacion horizontal vs regulacion sectorial

Las normativas de ciberseguridad se dividen en dos categorias. Las regulaciones horizontales (NIS2, RGPD, ENS) aplican a multiples sectores con requisitos generales. Las regulaciones sectoriales aplican requisitos especificos adaptados a los riesgos y particularidades de cada industria: PCI DSS para pagos, Ley PIC para infraestructuras criticas, normativa sanitaria para salud, DORA para finanzas.

Una organizacion tipica del sector financiero en Espana puede estar sujeta simultaneamente a ENS (si opera con el sector publico), NIS2 (como entidad esencial), DORA (como entidad financiera), PCI DSS (si procesa datos de tarjeta), RGPD (datos personales) y la normativa del Banco de Espana. Cada regulacion tiene sus propios requisitos, plazos, mecanismos de reporte y sanciones.

Este articulo analiza las principales regulaciones sectoriales que afectan a la ciberseguridad en Espana y la UE, con enfasis en PCI DSS 4.0, y propone una estrategia para gestionar el cumplimiento multi-regulacion sin multiplicar el esfuerzo.

PCI DSS 4.0: los 12 requisitos

PCI DSS (Payment Card Industry Data Security Standard) es el estandar de seguridad para organizaciones que almacenan, procesan o transmiten datos de tarjetas de pago. La version 4.0, publicada en marzo de 2022, sustituyo completamente a la version 3.2.1 el 31 de marzo de 2024. Los requisitos "future-dated" de la v4.0 entraron en vigor el 31 de marzo de 2025.

Los 12 requisitos de PCI DSS 4.0, agrupados en 6 objetivos de control:

Construir y mantener una red segura

Requisito 1: Instalar y mantener controles de seguridad de red. En PCI DSS 4.0, el termino "firewall" se ha sustituido por "controles de seguridad de red" para reflejar la diversidad de tecnologias actuales (firewalls tradicionales, WAF, microsegmentacion, SDN, cloud security groups). Se exige documentar y justificar todos los servicios, protocolos y puertos permitidos.

Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema. Prohibe configuraciones por defecto del fabricante. Exige un proceso documentado de hardening basado en estandares de la industria (CIS Benchmarks, STIG). Nuevo en v4.0: revision anual de las cuentas con acceso interactivo.

Proteger los datos de tarjeta

Requisito 3: Proteger los datos de cuenta almacenados. Minimizacion de datos: no almacenar datos de autenticacion sensibles (CVV, PIN) tras la autorizacion. Cifrado robusto con gestion de claves documentada. Nuevo en v4.0: cifrado de PAN en disco a nivel de campo, no solo a nivel de base de datos.

Requisito 4: Proteger los datos de tarjeta con criptografia fuerte en la transmision. TLS 1.2 como minimo (recomendado TLS 1.3). Prohibicion de SSL y TLS 1.0/1.1. Certificados validos y verificados. Nuevo en v4.0: inventario de certificados y claves con fechas de expiracion.

Mantener un programa de gestion de vulnerabilidades

Requisito 5: Proteger todos los sistemas contra malware. Antimalware en todos los sistemas susceptibles. Nuevo en v4.0: evaluacion periodica de sistemas considerados no susceptibles a malware para verificar que la clasificacion sigue siendo valida.

Requisito 6: Desarrollar y mantener software seguro. Practicas de desarrollo seguro. Revision de codigo o WAF para aplicaciones web publicas. Nuevo en v4.0: requisito de deteccion de cambios no autorizados en paginas de pago (prevencion de e-skimming y ataques Magecart). Scripts de terceros en paginas de pago deben estar inventariados y justificados.

Implementar controles de acceso robustos

Requisito 7: Restringir el acceso a datos de tarjeta por necesidad de negocio. Modelo de minimo privilegio documentado. Revisiones periodicas de acceso. Control de acceso basado en roles.

Requisito 8: Identificar usuarios y autenticar el acceso. Nuevo en v4.0: MFA (autenticacion multifactor) para todo acceso al entorno de datos de tarjeta (CDE), no solo para acceso remoto o administrativo como en v3.2.1. Contrasenas minimas de 12 caracteres (antes 7). Bloqueo de cuentas tras 10 intentos fallidos.

Requisito 9: Restringir el acceso fisico a los datos de tarjeta. Controles de acceso fisico a instalaciones con datos de tarjeta. Inventario de dispositivos de punto de venta (POS) con inspeccion periodica para detectar tampering.

Monitorizar y probar las redes

Requisito 10: Registrar y monitorizar todo el acceso. Logs de auditoria para todos los accesos a datos de tarjeta y componentes del CDE. Nuevo en v4.0: analisis automatizado de logs (antes la revision podia ser manual). Deteccion de fallos en sistemas de logging con alerta inmediata.

Requisito 11: Probar regularmente los sistemas y procesos de seguridad. Escaneo de vulnerabilidades interno trimestral y externo por ASV (Approved Scanning Vendor). Pentest anual interno y externo. Nuevo en v4.0: pentest de segmentacion cada 6 meses (antes anual). Monitoreo de integridad de archivos criticos con alerta.

Mantener una politica de seguridad

Requisito 12: Apoyar la seguridad con politicas y programas. Politica de seguridad revisada anualmente. Programa de concienciacion de seguridad. Nuevo en v4.0: analisis de riesgo personalizado (targeted risk analysis) para definir la frecuencia de controles periodicos, en lugar de frecuencias fijas para todos.

Cambios clave de PCI DSS 4.0 respecto a 3.2.1

La transicion de PCI DSS 3.2.1 a 4.0 no es una simple actualizacion de version. Introduce cambios estructurales en la filosofia del estandar.

Customized Approach

El cambio mas significativo. PCI DSS 4.0 permite a las organizaciones elegir entre el "Defined Approach" (cumplir el requisito tal como esta escrito, como en versiones anteriores) y el "Customized Approach" (implementar un control alternativo que cumpla el objetivo de seguridad del requisito). El Customized Approach requiere documentar el control alternativo, demostrar su efectividad y que sea validado por un QSA (Qualified Security Assessor).

MFA generalizado

PCI DSS 3.2.1 exigia MFA solo para acceso remoto al CDE y para acceso administrativo. PCI DSS 4.0 exige MFA para todo acceso al CDE, incluyendo acceso local desde la red interna. Esto afecta significativamente a organizaciones con personal que accede frecuentemente a sistemas con datos de tarjeta.

E-skimming y seguridad de paginas de pago

El requisito 6.4.3 exige que las organizaciones implementen mecanismos para detectar y alertar sobre cambios no autorizados en paginas de pago. Esto responde directamente a la epidemia de ataques Magecart y web skimming que han afectado a miles de sitios de comercio electronico. Se exige inventariar y justificar todos los scripts de terceros cargados en paginas de pago.

Targeted Risk Analysis

En lugar de imponer frecuencias fijas para todos los controles periodicos (escaneo trimestral, revision anual), PCI DSS 4.0 permite que las organizaciones definan frecuencias basadas en su propio analisis de riesgo. La organizacion debe documentar el analisis y justificar por que la frecuencia elegida es adecuada para su perfil de riesgo.

PCI DSS en el contexto espanol y europeo

PCI DSS no es una regulacion legal en la UE. Es un estandar contractual impuesto por las marcas de pago (Visa, Mastercard, Amex, Discover, JCB) a traves de los acuerdos con los adquirentes y procesadores de pago. Sin embargo, su cumplimiento es efectivamente obligatorio para cualquier organizacion que procese pagos con tarjeta.

En Espana, PCI DSS coexiste con el ENS (para entidades que operan con la administracion publica), NIS2 (para entidades esenciales e importantes), RGPD (los datos de tarjeta son datos personales) y la normativa del Banco de Espana (para entidades financieras). Esta superposicion genera dos desafios: solapamiento de requisitos (los mismos controles se auditan bajo multiples marcos) y conflictos potenciales (un requisito PCI DSS puede implementarse de forma que no satisfaga un requisito ENS).

El PCI SSC (Payment Card Industry Security Standards Council) ha publicado documentos de orientacion sobre la relacion entre PCI DSS y RGPD, reconociendo que ambos marcos se complementan pero no se sustituyen. El cifrado de PAN exigido por PCI DSS contribuye a la proteccion de datos personales del RGPD, pero PCI DSS no cubre todos los derechos del interesado que exige el RGPD.

Regulacion sanitaria

El sector salud maneja datos especialmente sensibles (datos de salud, categoria especial bajo RGPD articulo 9) y opera infraestructuras criticas cuya indisponibilidad puede tener impacto directo en vidas humanas.

Marco regulatorio en la UE

A diferencia de Estados Unidos con HIPAA, la UE no tiene una regulacion especifica de ciberseguridad para el sector salud a nivel europeo. La proteccion se articula a traves de la combinacion de RGPD (datos de salud como categoria especial), NIS2 (hospitales y proveedores sanitarios como entidades esenciales), la Directiva sobre dispositivos medicos (MDR 2017/745) y las regulaciones nacionales.

Regulacion sanitaria en Espana

En Espana, los centros sanitarios publicos estan sujetos al ENS. Los hospitales del Sistema Nacional de Salud que procesan datos con sistemas de informacion del sector publico deben cumplir ENS en la categoria correspondiente a la sensibilidad de los datos que manejan (tipicamente Alta para historiales clinicos).

La Ley 41/2002 de autonomia del paciente establece requisitos de confidencialidad, integridad y disponibilidad de la historia clinica que se traducen en controles de ciberseguridad: control de acceso basado en la relacion asistencial, trazabilidad de accesos a historiales, conservacion minima de 5 anos.

El Esquema de Certificacion de Ciberseguridad (bajo el marco europeo de certificacion del Reglamento de Ciberseguridad) afectara progresivamente a los dispositivos medicos conectados (IoMT, Internet of Medical Things), que son un vector de ataque creciente en entornos hospitalarios.

Riesgos especificos del sector salud

Los ataques de ransomware a hospitales han demostrado que la ciberseguridad en salud no es solo una cuestion de privacidad. La indisponibilidad de sistemas clinicos (HIS, PACS, laboratorio) puede retrasar diagnosticos y tratamientos. Los dispositivos medicos conectados (bombas de infusion, monitores, equipos de imagen) tienen ciclos de vida largos con actualizaciones infrecuentes. La telemedicina ha ampliado la superficie de ataque.

Infraestructuras criticas: Ley PIC y CNPIC

La proteccion de infraestructuras criticas en Espana se regula por la Ley 8/2011 (Ley PIC) y su desarrollo reglamentario (RD 704/2011). El organismo responsable es el CNPIC (Centro Nacional de Proteccion de Infraestructuras y Ciberseguridad), integrado en la Secretaria de Estado de Seguridad del Ministerio del Interior.

Sectores estrategicos

La Ley PIC define 12 sectores estrategicos: energia, industria nuclear, tecnologias de la informacion y las comunicaciones, transporte, agua, alimentacion, salud, sistema financiero y tributario, administracion, industria quimica, espacio e instalaciones de investigacion.

Obligaciones de los operadores criticos

Los operadores criticos (designados por el CNPIC tras un proceso de analisis) deben elaborar un Plan de Seguridad del Operador (PSO), que incluye la politica general de seguridad de la organizacion, y Planes de Proteccion Especificos (PPE) para cada infraestructura critica designada. Estos planes deben incluir medidas de ciberseguridad especificas.

Desde la transposicion de NIS2 (prevista mediante Real Decreto que refunde la Ley PIC con los requisitos NIS2), los operadores criticos que sean tambien entidades esenciales bajo NIS2 tendran un marco unificado de obligaciones. Hasta entonces, coexisten ambos marcos con requisitos que se solapan parcialmente.

CNPIC y gestion de incidentes

Los operadores criticos deben reportar incidentes de ciberseguridad al CNPIC a traves del CERTSI (ahora integrado en INCIBE-CERT para el sector privado y CCN-CERT para el sector publico). Los plazos de notificacion se alinearan con NIS2 (alerta inicial en 24 horas, notificacion en 72 horas, informe final en un mes).

Telecomunicaciones

El sector de telecomunicaciones tiene su propia regulacion sectorial en materia de seguridad. En Espana, la Ley 11/2022 General de Telecomunicaciones transpone la Directiva (UE) 2018/1972 (Codigo Europeo de Comunicaciones Electronicas).

Obligaciones de seguridad

Los operadores de telecomunicaciones deben adoptar medidas tecnicas y de gestion adecuadas para gestionar los riesgos de seguridad de las redes y servicios. Deben notificar incidentes de seguridad significativos a la autoridad competente (Secretaria de Estado de Telecomunicaciones e Infraestructuras Digitales) y, en caso de incidentes que afecten a los usuarios, informar a estos directamente.

Con NIS2, los operadores de telecomunicaciones se clasifican como entidades esenciales, lo que anade las obligaciones de NIS2 a las ya existentes bajo la Ley General de Telecomunicaciones. La supervision pasa a incluir tanto al regulador sectorial como a la autoridad NIS2 competente.

5G y requisitos adicionales

El despliegue de redes 5G ha generado regulacion adicional. En Espana, el Real Decreto-ley 7/2022 sobre requisitos para garantizar la seguridad de las redes y servicios 5G establece obligaciones especificas: analisis de riesgos de la cadena de suministro, restricciones a proveedores de alto riesgo, diversificacion de suministradores, requisitos de seguridad para equipos y componentes criticos de la red.

Sector energetico

El sector energetico (electricidad, gas, petroleo) esta sujeto a regulacion sectorial especifica ademas de los marcos horizontales.

En la UE, la Directiva (UE) 2022/2557 sobre resiliencia de entidades criticas (CER) complementa a NIS2 para el sector energetico, anadiendo requisitos de resiliencia fisica y operativa. En Espana, la regulacion energetica (Ley del Sector Electrico, regulacion de la CNMC) incluye requisitos de seguridad para los operadores del sistema electrico, los transportistas y los distribuidores.

Los sistemas de control industrial (ICS/SCADA/OT) del sector energetico tienen requisitos de ciberseguridad especificos. El estandar IEC 62351 aborda la seguridad de los protocolos de comunicacion del sistema electrico. El NERC CIP (Critical Infrastructure Protection), aunque de origen norteamericano, es referencia para el sector energetico global. En Europa, ENISA ha publicado guias sectoriales para la ciberseguridad del sector energetico alineadas con NIS2.

La convergencia IT/OT en el sector energetico (smart grids, contadores inteligentes, gestion remota de subestaciones) amplifica los riesgos de ciberseguridad y requiere controles especificos que las regulaciones horizontales no cubren en detalle.

Sector financiero mas alla de DORA

DORA (Digital Operational Resilience Act) es la regulacion principal de resiliencia digital para el sector financiero en la UE, pero no es la unica. En Espana, el sector financiero esta sujeto a regulacion adicional.

Banco de Espana

Las circulares del Banco de Espana incluyen requisitos de seguridad para entidades de credito. La Circular 2/2016 sobre supervision y solvencia establece obligaciones de gestion de riesgos tecnologicos. Las guias de supervision del Banco de Espana sobre riesgo tecnologico detallan expectativas en materia de ciberseguridad, continuidad de negocio y externalizacion de servicios TIC.

CNMV

La Comision Nacional del Mercado de Valores regula la ciberseguridad de las empresas de servicios de inversion, sociedades gestoras, mercados regulados e infraestructuras de mercado. La Circular 1/2022 de la CNMV incluye requisitos de gobernanza TIC, gestion de incidentes y continuidad de negocio alineados con DORA.

EBA y BCE

A nivel europeo, las directrices de la EBA (European Banking Authority) sobre gestion de riesgos TIC y seguridad (EBA/GL/2019/04) complementan DORA con requisitos especificos para entidades de credito. El BCE (Banco Central Europeo) supervisa directamente la ciberseguridad de las entidades significativas de la zona euro a traves del Mecanismo Unico de Supervision (MUS/SSM) y el marco TIBER-EU para pruebas de resiliencia.

Seguros

El sector asegurador esta sujeto a las directrices de EIOPA (European Insurance and Occupational Pensions Authority) sobre seguridad TIC y gobernanza, ademas de DORA. Solvencia II incluye requisitos de gestion de riesgos operacionales que abarcan la ciberseguridad.

Estrategia de cumplimiento multi-regulacion

Cuando una organizacion esta sujeta a 4, 5 o 6 regulaciones de ciberseguridad simultaneamente, el enfoque de cumplirlas por separado es insostenible. Multiplica el esfuerzo, genera inconsistencias y produce fatiga de auditoria.

Marco de control unificado

La estrategia recomendada es construir un marco de control unificado interno (Unified Control Framework, UCF) que mapee todos los requisitos regulatorios aplicables a un conjunto comun de controles.

El proceso tiene cuatro pasos. Primero, inventariar todas las regulaciones aplicables con sus requisitos especificos. Segundo, mapear los requisitos a un framework de referencia (ISO 27001 Anexo A, NIST CSF o CIS Controls como base). Tercero, identificar solapamientos (un mismo control cubre requisitos de multiples regulaciones) y gaps (requisitos especificos que no se cubren con controles genericos). Cuarto, implementar los controles una vez y documentar la trazabilidad de cada control hacia los requisitos que cubre.

Herramientas de apoyo

El CCN proporciona la Guia CCN-STIC 825 con la correspondencia ENS/ISO 27001. El PCI SSC ha publicado mappings entre PCI DSS y ISO 27001, NIST CSF y CIS Controls. ENISA ofrece mappings entre NIS2 y ISO 27001. Estas correspondencias son el punto de partida para construir el marco unificado.

Las plataformas GRC (Governance, Risk and Compliance) como ServiceNow GRC, Archer, OneTrust o soluciones europeas como CISO Assistant facilitan la gestion del marco unificado al permitir vincular controles con multiples requisitos normativos y generar informes de cumplimiento por regulacion a partir de las mismas evidencias.

Gestion de evidencias

El mayor coste operativo del cumplimiento multi-regulacion no es implementar los controles, sino generar y mantener las evidencias. La automatizacion de la recogida de evidencias (Compliance-as-Code, integracion con herramientas de seguridad, dashboards automatizados) reduce drasticamente este coste.

Una evidencia bien disenada sirve para multiples regulaciones. Un log de acceso que demuestre control de acceso basado en roles cubre simultaneamente el requisito 7 de PCI DSS, el control A.9 de ISO 27001, la medida op.acc del ENS y el articulo 21 de NIS2. La clave es disenar la evidencia una vez pensando en todos los marcos que debe cubrir.

Priorizacion por riesgo de sancion

No todas las regulaciones tienen el mismo peso en terminos de riesgo. Las sanciones varian enormemente: NIS2 puede imponer hasta 10M EUR o 2% de facturacion global para entidades esenciales, RGPD hasta 20M EUR o 4% de facturacion global, mientras que PCI DSS impone penalizaciones contractuales a traves de los adquirentes (tipicamente entre 5.000 y 100.000 USD mensuales).

La priorizacion del esfuerzo de cumplimiento debe considerar no solo las sanciones, sino tambien el riesgo reputacional, la probabilidad de inspeccion y las consecuencias operativas del incumplimiento (perdida de la capacidad de procesar pagos en el caso de PCI DSS, inhabilitacion de consejeros en el caso de NIS2).

Recursos y referencias

Para profundizar en regulacion sectorial de ciberseguridad:

• PCI SSC Document Library: Todos los documentos PCI DSS 4.0, guias de implementacion, SAQs y ROC templates. Disponibles en pcisecuritystandards.org.
• CCN-STIC 825: Correspondencia ENS/ISO 27001. Util como base para el marco de control unificado.
• CNPIC: Informacion sobre infraestructuras criticas en Espana, designacion de operadores y requisitos de planes de seguridad.
• ENISA Good Practices for Security of Healthcare Services: Guia de ENISA para ciberseguridad en el sector sanitario europeo.
• Ley 11/2022 General de Telecomunicaciones: Marco regulatorio de telecomunicaciones en Espana, incluyendo requisitos de seguridad de redes.
• DORA Regulation (EU) 2022/2554: Texto completo del reglamento de resiliencia operativa digital para el sector financiero.
• EBA/GL/2019/04: Directrices de la EBA sobre gestion de riesgos TIC y seguridad para entidades de credito.
• IEC 62351: Estandar de seguridad para protocolos de comunicacion del sistema electrico. Referencia para el sector energetico.
• NIST SP 800-82 Rev. 3: Guide to OT Security. Referencia para ciberseguridad de sistemas de control industrial en infraestructuras criticas.