El cifrado como ventaja para el cumplimiento del RGPD en el sector de los servicios financieros

Durante la mayor parte de las últimas tres décadas, la criptografía permaneció en un segundo plano en el sector de los servicios financieros. Los equipos de seguridad y de infraestructura de clave pública (PKI) se encargaban de gestionarla, los equipos de cumplimiento normativo rara vez se paraban a pensar en ella y todo el mundo la consideraba un mero detalle técnico. El RGPD contribuyó a poner fin a esa era. El cifrado es ahora una cuestión de gobernanza y cumplimiento normativo que se aborda en las reuniones de la junta directiva, en las inspecciones regulatorias y en los planes de respuesta ante violaciones de seguridad.

Ese cambio supone una buena noticia si sabes cómo aprovecharlo. En el marco del RGPD, el cifrado sólido no es solo un coste derivado del cumplimiento normativo, sino también una herramienta. Un cifrado bien implementado de los datos financieros puede reducir tu exposición a las violaciones de seguridad, eximirte de la obligación de notificar dichas violaciones y agilizar las auditorías y los procesos de diligencia debida que, cada vez más, condicionan las relaciones comerciales. Este artículo explica cómo aborda el RGPD el cifrado de los datos financieros y cómo convertir el artículo 32 en una ventaja en lugar de una obligación.

Por qué el RGPD sigue marcando la pauta en materia de datos financieros

El RGPD (Reglamento (UE) 2016/679) está en vigor desde mayo de 2018 y sigue siendo el punto de referencia mundial en materia de protección de datos. Su influencia se extiende mucho más allá de Europa. El RGPD se aplica en toda la UE y el EEE sobre la base de dos fundamentos independientes. El artículo 3, apartado 1, abarca el tratamiento realizado en el contexto de las actividades de un establecimiento de la UE, independientemente del lugar físico en el que se lleve a cabo dicho tratamiento. El artículo 3, apartado 2, se aplica a las organizaciones que no cuentan con ningún establecimiento en la UE, siempre que ofrezcan bienes o servicios a personas que se encuentren en la Unión o supervisen el comportamiento de estas. Cabe destacar el criterio: se basa en la ubicación de la persona, no en su ciudadanía ni en su residencia. Este alcance reviste especial importancia para los servicios financieros. Las redes de pagos transfronterizos, las relaciones de corresponsalía y las plataformas bancarias centrales alojadas en la nube hacen que la mayoría de las entidades tengan acceso, en algún momento, a los datos de personas que se encuentran en la UE. Dado que tantas organizaciones deben cumplir la normativa del RGPD, esta define lo que los reguladores de todo el mundo consideran una seguridad razonable, incluso en mercados en los que el RGPD no se aplica directamente.

Los datos que las entidades financieras tratan realmente

Las entidades financieras gestionan datos que, con frecuencia, se consideran de alto riesgo según el criterio basado en el riesgo del RGPD. Destacan tres categorías:

• Historiales de transacciones que revelan el comportamiento, las relaciones y la situación financiera de los clientes.
• Datos sobre solvencia y capacidad de pago que se utilizan en las decisiones de concesión de préstamos y suscripción.
• Datos de autenticación biométrica utilizados en la prevención del fraude.

La sensibilidad y el volumen de estos datos hacen que su protección cobre una importancia aún mayor. Cuando la información subyacente es tan reveladora, el cifrado deja de ser un elemento prescindible y se convierte en un elemento fundamental para demostrar que se cuenta con la seguridad adecuada.

Lo que está en juego: multas y la exención de la obligación de notificar las violaciones de seguridad

El RGPD plantea a las entidades financieras dos caras de la misma moneda.

Por el contrario, las multas pueden alcanzar los 20 millones de euros o el 4 % de la facturación anual global, lo que sea mayor. El sector de los servicios financieros se ha situado sistemáticamente entre los más sancionados, dado el volumen y la sensibilidad de los datos que trata. La insuficiencia de las medidas de seguridad técnicas y organizativas es actualmente el motivo más habitual de las sanciones en el sector financiero y de seguros. Dado que el artículo 32 se basa en el riesgo y no es prescriptivo, las autoridades de supervisión y los tribunales tienen en cuenta las prácticas de cifrado y gestión de claves que se aplicaban realmente en el momento del incidente, y no lo que se establecía en un documento normativo.

Por el lado positivo, el cifrado tiene una ventaja directa recogida en el reglamento. Según el artículo 34, apartado 3, letra a), el responsable del tratamiento no está obligado a notificar a los interesados una violación de seguridad si los datos expuestos se han vuelto ininteligibles para terceros no autorizados, normalmente mediante un cifrado sólido.  Esta exención no es de aplicación automática. Debe poder demostrar que el algoritmo era de última generación, que la clave quedaba fuera del alcance de la violación de seguridad y que el material de clave se conservaba separado de los datos. Un cifrado sólido y con claves adecuadas puede marcar la diferencia entre una simple notificación administrativa y una notificación pública a todos los clientes afectados.

Quiénes son los responsables: los responsables del tratamiento, los encargados del tratamiento y los delegados de protección de datos

El RGPD asigna funciones claras, pero no de forma equitativa. La responsabilidad en materia de criptografía recae en el responsable del tratamiento, según el artículo 24, y, cuando proceda, en el encargado del tratamiento. El delegado de protección de datos (DPO) asesora y supervisa, según el artículo 39, y no puede ser considerado responsable del cifrado ni de la gestión de claves.

• Los responsables del tratamiento son las entidades financieras que determinan los fines y los medios del tratamiento de los datos de los clientes, de las cuentas y de las transacciones.
• Los encargados del tratamiento son los procesadores de pagos, los proveedores de servicios en la nube y los proveedores de servicios externalizados que tratan datos personales por cuenta del responsable del tratamiento.
• Por lo general, las empresas financieras están obligadas a contar con responsables de protección de datos, dada la supervisión sistemática y a gran escala que conlleva la evaluación de riesgos y la detección de fraudes.

Entender quién es el responsable de cada obligación te ayuda a atribuir la responsabilidad del cifrado, la gestión de claves y la garantía de los proveedores a quien corresponde.

Cómo se corresponde el RGPD con los controles criptográficos

La idea clave para las entidades financieras es que el artículo 32 se basa en el riesgo y no es de carácter prescriptivo. No ofrece una lista de algoritmos. En su lugar, las autoridades de supervisión analizan las prácticas de criptografía y gestión de claves que se aplican realmente cuando se produce un incidente, y no lo que establece una política. Por ello, el objetivo es contar con una criptografía demostrable y bien gestionada. Siete áreas de control interrelacionadas muestran dónde entra en juego el cifrado.

Seguridad del tratamiento (artículo 32, apartado 1, letra a))

Cifrar y seudonimizar los datos de los clientes y de las transacciones, tanto en reposo como en tránsito, de acuerdo con el riesgo que entrañe la actividad de tratamiento. Los tratamientos que entrañan un mayor riesgo requieren una protección más sólida.

Protección de datos desde el diseño y de forma predeterminada (artículo 25)

Incorporar controles criptográficos ya en la fase de diseño del sistema. Los almacenes de datos cifrados y las API deben ser la configuración por defecto, no un control añadido a posteriori.

Exención de la obligación de notificar las violaciones de seguridad (artículo 34, apartado 3, letra a))

Mantén un cifrado sólido y demostrable que te permita quedar exento de la obligación de notificar a los interesados de forma individual cuando los datos expuestos se hayan vuelto ilegibles. Lo importante es poder demostrarlo, no solo afirmarlo.

Gestión de claves y control de acceso (artículo 32, apartado 1, letra b))

Gestiona el ciclo de vida de las claves con un acceso restringido a las mismas. Esto garantiza la confidencialidad, la integridad, la disponibilidad y la resiliencia continuas de los sistemas de procesamiento, tal y como exige el RGPD.

Pruebas y restauración (artículo 32, apartado 1, letras c) y d))

El artículo 32, apartado 1, letra d), exige un proceso para comprobar y evaluar periódicamente si las medidas siguen siendo eficaces, y es esta disposición la que convierte la obsolescencia de un algoritmo en un incumplimiento normativo. El artículo 32, apartado 1, letra c), exige la capacidad de restauración, y está directamente relacionado con la exención en caso de violación de la seguridad: los datos cifrados sin copia recuperable siguen constituyendo un incidente de disponibilidad.

Garantías en materia de transferencias transfronterizas (artículo 46)

Utilizar el cifrado de los datos en tránsito como medida técnica complementaria que respalde los mecanismos de transferencia internacional, como las cláusulas contractuales tipo.

Garantías criptográficas del responsable del tratamiento y del proveedor (artículo 28)

Mantenga un inventario de componentes criptográficos que permita llevar a cabo la debida diligencia respecto a los procesadores y subprocesadores de pagos que tratan datos personales en su nombre.

Prepararse para la auditoría: lo que realmente preguntan los auditores

Las evaluaciones y los exámenes se centran en las pruebas demostradas, no solo en las declaraciones de política. Esta realidad favorece a las instituciones que pueden mostrar su trabajo. Utiliza lo siguiente como lista de verificación para la autoevaluación:

• Una evaluación de riesgos documentada, conforme al artículo 32, que justifique la elección de las medidas de cifrado y seudonimización.
• Cobertura del cifrado o la seudonimización en todos los sistemas que tratan datos personales, no solo en los que están orientados al exterior.
• Pruebas documentadas de que los datos expuestos en un incidente hipotético seguirían siendo ininteligibles.
• Registros de protección de datos desde el diseño, con controles criptográficos reflejados en las evaluaciones de impacto relativas a la protección de datos.
• Pruebas de que se realizan pruebas y evaluaciones periódicas de sus controles criptográficos, incluida una posición documentada sobre la obsolescencia de los algoritmos.
• Acuerdos con los encargados del tratamiento y los subencargados del tratamiento que regulan las prácticas criptográficas.
• Pruebas de que el acceso a las claves que protegen los datos personales está restringido y se registra.
• Un inventario criptográfico y un plan de migración para la preparación ante la era poscuántica.

Si puedes responder a cada punto con documentación en lugar de con simples garantías, estarás en una posición sólida cuando el examinador te pregunte.

Cómo Keyfactor ayudarte Keyfactor

Cumplir estas obligaciones a gran escala es una cuestión de visibilidad, automatización y control del ciclo de vida. Keyfactor vincula cada área de control del RGPD con una capacidad práctica, para que puedas poner en práctica el artículo 32 en lugar de limitarte a describirlo.

• AgileSec proporciona el inventario de componentes criptográficos que sirve de base para la diligencia debida de los encargados del tratamiento y los subencargados (artículo 28).
• EJBCA Ofrece servicios de emisión de certificados y una infraestructura de clave pública (PKI) escalable y preparada para el futuro. Permite proteger los datos en reposo y en tránsito (artículo 32, apartado 1, letra a)), permite acogerse a la exención de la notificación de violaciones de seguridad (artículo 34, apartado 3, letra a)) y respalda las garantías para las transferencias transfronterizas (artículo 46).
• Bouncy Castle ofrece un amplio catálogo de primitivas criptográficas robustas que permiten proteger los datos y facilitan el cumplimiento normativo.
• Keyfactor Command apoya la protección de datos desde el diseño (artículo 25) y una gestión del ciclo de vida de las claves con un acceso restringido y auditable a las mismas (artículo 32, apartado 1, letra b)).

El denominador común es la madurez. Las instituciones que desarrollan una gestión madura de la visibilidad criptográfica y del ciclo de vida de los certificados superan con mayor rapidez los procesos de diligencia debida y las inspecciones, y se recuperan más rápidamente cuando cambian los certificados o los algoritmos. En este sentido, la gobernanza criptográfica se convierte en una ventaja competitiva, y no solo en una medida defensiva.

Conclusión y próximos pasos

En virtud del RGPD, un cifrado bien implementado cumple dos funciones a la vez. Por un lado, es un escudo frente a multas que pueden alcanzar los 20 millones de euros o el 4 % de la facturación global; por otro, constituye una exención que puede evitarte tener que notificar a todos los clientes afectados tras una violación de datos. Ambas ventajas dependen de una criptografía que puedas demostrar realmente, no de una que simplemente afirmes tener.

Los primeros pasos prácticos son los mismos independientemente de por dónde se empiece. Obtén una visión clara de los activos criptográficos de los que dispones y de dónde están implementados. Evalúalos según los requisitos del artículo 32. A continuación, automatiza los ciclos de vida de los certificados y las claves antes de que las deficiencias se conviertan en incidentes. ¿Estás listo para ver cómo? Solicitar una demo.

¿Tienes dudas sobre el cifrado en el marco del RGPD? Tenemos las respuestas.

Does GDPR require encryption of personal data?
GDPR does not mandate encryption outright. Article 32 names encryption and pseudonymization as example measures appropriate to the risk, so the requirement is risk-based. For high-risk financial data, encryption is generally expected.

What personal data do financial institutions need to protect under GDPR?
Typically high-risk categories such as transaction histories, credit and affordability data, and biometric authentication data used in fraud prevention. These carry heightened obligations because of their sensitivity and volume.

How large can GDPR fines be for financial services?
Fines can reach EUR 20 million or 4% of global annual turnover, whichever is higher. Financial services has consistently been among the more heavily fined sectors, given the volume and sensitivity of data it processes.

Can encryption exempt us from notifying customers after a breach?
Yes, under Article 34(3)(a). If exposed data was rendered unintelligible to unauthorized parties, usually through strong encryption, the controller does not have to notify individual data subjects. This makes encryption a direct cost-avoidance control.

Which GDPR articles matter most for cryptography?
Article 32 (security of processing, including pseudonymization and encryption), Article 25 (data protection by design and by default), Article 5(1)(f) and 5(2) (the confidentiality principle and the duty to demonstrate compliance), and Articles 33 and 34, where encryption is not just mitigating but can remove the duty to notify individuals altogether.

What do supervisor authorities look for?
Documented evidence, not policy statements alone. Expect questions about the Article 32 risk assessment, encryption coverage across all processing systems, breach safe-harbor support, data protection by design records, processor assurance, and restricted, logged key access.

Do our payment processors and vendors fall under GDPR encryption expectations?
Yes. Under Article 28, processor agreements should address the cryptographic practices of payment processors and sub-processors. A cryptographic component inventory helps support that due diligence.

Is GDPR only relevant to organizations based in the EU?
No. GDPR applies in the EU and EEA but has extraterritorial reach to any organization processing the personal data of EU residents, which is why it shapes what regulators worldwide consider reasonable security.