Source: https://blog.isecauditors.com/2018/
Timestamp: 2019-11-23 01:01:41
Document Index: 366517174

Matched Legal Cases: ['artículo 94', 'artículo 95', 'artículo 6', 'artículo 7', 'artículo 6', 'artículo 32', 'artículo 1', 'artículo 4', 'artículo 2', 'artículo 4', 'artículo 11', 'artículo 11', 'artículo 2', 'artículo 1', 'artículo 44', 'artículo 45', 'artículo 51', 'artículo 52', 'artículo 40', 'artículo 99', 'artículo 55', 'artículo 33', 'artículo 83']

2018 | Blog de Internet Security Auditors
Requisitos de seguridad en PSD2
Cuando hablamos de PSD2 (Directiva (UE) 2015/2366) todos pensamos en el requerimiento de los bancos de disponer de APIs para que las fintech puedan acceder a los datos de sus clientes sin necesidad de realizar técnicas de screen scraping (técnica que queda expresamente prohibida), pero la Directiva va más allá.
En esta entrada nos vamos a centrar en los artículos que incluyen exigencias de seguridad para los proveedores de servicios de pago (PSP), que, aunque son pocos artículos, hacen referencias a reglamentos delegados y directrices marcadas por la Autoridad Bancaria Europea (EBA, por sus siglas en inglés).
El artículo 94, Protección de datos, si bien es bastante escueto, indica la necesidad de cumplir con las directivas de protección de datos y las normas naciones de transposición; al ser PSD2 una Directiva de 2015, no hace referencias al RGPD (Reglamento 2016/679), cosa que sí se incluye esta referencia en el anteproyecto de ley que se ha publicado en España para trasponer la Directiva 2015/2366. En resumen, se permitirá el tratamiento de datos personales para la prevención y descubrimiento del fraude, siempre de forma adecuada a lo estipulado en la legislación de cada país.
Riesgos: Operativos y de seguridad
Es en el artículo 95, Gestión de los riesgos operativos y de seguridad, donde se indica que la EBA debe publicar unas guías con medidas de seguridad que deberán adoptar los proveedores de servicios de pago. Estas directrices fueron publicadas en diciembre de 2017 y se estructuran en 9 apartados que vemos a continuación:
Este apartado sirve como introducción e indica que los puntos sucesivos deben servir como guía, ya que el nivel de detalle dependerá en función de la naturaleza, alcance, complejidad y riesgo de los servicios que preste el PSP (Proveedor de Servicios de Pago).
En este apartado se indica la necesidad de que exista, dentro de la Organización, un framework de seguridad, aprobado y revisado por la Dirección al menos una vez al año (muy en la línea de que indica la ISO 27001).
También (y nuevamente, alineado con los estándares ISO), indica que la gestión de la seguridad debe basarse en un modelo de gestión de riesgos. Esta gestión de riesgos estará documentada y deberá estar aprobada por la Dirección (además de ser consistente con el apetito por el riesgo de la Organización). Este análisis de riesgos debe ejecutarse de forma periódica y cada vez que haya un cambio significativo que afecte a los servicios de pago.
También se menciona la necesidad de establecer 3 líneas de defensa o un sistema de gestión de riesgos y control equivalente. Generalmente, cuando hablamos de 3 líneas de defensa, incluimos por un lado la existencia de controles operativos; el segundo nivel es el de supervisión, que revisa los resultados de dichos controles y el tercer nivel es el de una auditoría (generalmente auditoría interna), que verifica todo el proceso de supervisión y que los controles sean acordes y adecuados a las necesidades.
Las auditorías son exigidas en este mismo apartado, y deben ser llevadas a cabo por personal independiente al PSP; la frecuencia y alcance de la auditoría dependerá de los riesgos de seguridad tenidos en consideración.
También se hacen referencias en este grupo de controles al control de proveedores, indicando que el PSP debe establecer controles cuando haya funciones operacionales externalizadas y que se deben definir objetivos de seguridad y de rendimiento a través de acuerdos de nivel de servicio (SLAs).
Ya se ha hecho mención al marco de gestión de riesgos, pero este apartado profundiza. Se menciona la necesidad de identificar y establecer (y mantener actualizado) un inventario de activos, que incluya las principales funciones de negocio, roles clave y procesos de soporte y que sirva para clarificar la importancia e interrelación de cada uno de ellos en relación con los riesgos de seguridad y operacionales.
En esta misma línea, y como indican la mayoría de los estándares de seguridad (estándares ISO o PCI DSS), se indica la necesidad de identificar y disponer de un inventario de activos actualizado regularmente.
Como es habitual en los análisis de riesgos, tanto los activos como los procesos identificados tendrán que ser clasificados en términos de criticidad. No se hace ninguna referencia a esta clasificación, pudiéndose hacer de forma cuantitativa o cualitativa, a deseo del PSP.
En este apartado se indica la necesidad de monitorizar de forma continua las amenazas y vulnerabilidades, así como revisar de forma periódica los escenarios de riesgo que tienen impacto sobre los procesos de negocio. En base a esto, las directrices exigen que se realice un análisis de riesgos con una periodicidad anual o cada vez que se realice un cambio significativo (nuevamente, en línea con los principales estándares de seguridad como PCI DSS o ISO 27001).
Siguiendo las metodologías de análisis de riesgos habituales, el siguiente punto de estas directrices indica la necesidad de tratar los riesgos derivados de la evaluación anterior.
Este es sin duda uno de los apartados más ambiguos de estas directrices, dejando libertad al PSP de implantar las medidas que más se adecúen a él; según indica, el PSP deberá establecer e implantar medidas de seguridad preventiva que dependerán de los resultados del análisis de riesgos realizado (y, por tanto, será también labor del auditor externo comprobar y analizar si estas medidas son adecuadas a los riesgos inherentes de la Organización). Medidas de seguridad basadas en los riesgos, tal y como se indica en estándares como ISO 27001 o las legislaciones actuales (RGPD).
Además, el PSP debe establecer una ‘defensa en profundidad’, es decir, debe establecer controles de seguridad que cubran los diferentes activos (personas, procesos y tecnología) involucrados en el servicio de pagos.
Se hace también una aclaración en relación al concepto "defensa en profundidad", indicando que se requiere de al menos dos controles para cada riesgo y pone como ejemplos que haya dos factores de autenticación o que se implante, además de segmentación de redes, firewalls entre dichos segmentos.
Estos controles deben estar enfocados a proteger la confidencialidad, integridad y disponibilidad de los activos críticos (sean lógicos o físicos), recursos e información y que se debe velar por estos principios en cualquier estado en el que la información se encuentre (en uso, en tránsito o durante su almacenamiento). Nuevamente se menciona en este punto la necesidad de cumplir con la legislación vigente y hace especial mención al RGPD.
Cuando se realice un cambio en la infraestructura, el PSP deberá evaluar si ese cambio requiere de cambios en los controles existentes o si son necesarios nuevos controles de seguridad.
El siguiente punto es básico en materia de seguridad y requiere que haya segregación de funciones y la utilización de principios de "least privilege". También en este punto se indica que se deben segregar los entornos IT para el desarrollo, pruebas y producción.
Los datos que se obtengan deben limitarse a los requeridos para el servicio o negocio (deben ser relevantes y adecuados) y que deben considerarse su necesidad en la obtención, procesamiento, almacenamiento y visualización (vemos aquí una referencia directa a PCI, por ejemplo). Nuevamente, este control va muy alineado con los nuevos reglamentos europeos como el RGPD.
Se deben tener controles para asegurar que los parches de seguridad se aplican al software.
El siguiente control, si bien bastante simple a priori, es probablemente de los más complejos. Según indica, el PSP debe disponer de medidas de seguridad físicas adecuadas, en especial para proteger la información sensible de pago. Es lo único que dice, pero no indica qué son ‘medidas de seguridad físicas adecuadas’; obviamente, esto dependerá del análisis de riesgos y la información que se esté procesando y/o almacenando, pero no da ninguna indicación de las medidas de seguridad, por lo que estarán supeditadas al criterio del auditor (ya que en principio el auditor deberá comprobar los controles de seguridad).
El siguiente control indica que se debe autorizar los accesos únicamente a personal autorizado y que estarán en concordancia con sus responsabilidades (ya habíamos mencionado anteriormente la necesidad de existencia del least privilege), que estarán alineadas con las necesidades de negocio.
Mención especial a los controles de accesos de administradores, para los que indica que es necesario establecer “controles fuertes”. Para el caso concreto de la administración remota, indica específicamente la necesidad de utilizar autenticación fuerte. También indica en este punto que estos accesos deben ser supervisados (logs), revisados periódicamente y estar estrictamente limitados basados en la necesidad del saber. Algunos puntos más adelante, sí que indica claramente que el acceso remoto de administradores requerirá que se utilice autenticación fuerte.
Los logs de acceso deberán ser almacenados durante un periodo de tiempo alineado con las funciones de negocio y criticidad de los activos (obviamente, siempre alineado también con los requerimientos legales).
Hay un último punto en este apartado que indica que, si se utilizan herramientas, productos o algún tipo de software para gestionar en control de accesos, deben existir controles que prevengan que se puedan comprometer o circunvalar la protección dada por estas herramientas.
En este listado de controles se habla de la monitorización continua y la detección de amenazas. Para ello, el PSP deberán implementar procesos y dotar de recursos que permitan monitorizar las funciones de negocio, procesos de soporte y activos de la información de forma continua para detectar actividades anómalas, ya sea a nivel físico o lógico.
Estos procesos deberán cubrir:
Factores internos y externos relevantes.
Transacciones, de cara a detectar usos inadecuados de acceso por proveedores de servicio u otras entidades.
Potenciales amenazas internas o externas.
También deberán incluirse controles que permitan identificar fugas de información, código malicioso y otras amenazas para la seguridad, así como controles para estar al día de las vulnerabilidades del software y hardware que se utiliza en los servicios de pago.
Además, deberán establecerse criterios y umbrales para clasificar los eventos de seguridad (de forma que se pueda saber si se trata de un "evento" o un "incidente", así como la criticidad del mismo).
Y obviamente, el PSP deberá disponer de disponer de medidas y recursos que se encarguen de cumplir estos procesos y controles y reportarlos a la alta dirección en caso de ser necesario.
Se deberá implantar mecanismos que se encarguen de gestionar la continuidad del servicio de pago en caso de disrupción. Obviamente, la continuidad de negocio tendrá que ir en línea con la exposición a amenazas que tenga el PSP y el impacto potencial sobre las funciones críticas de negocio (que podrá ser un análisis cuantitativo o cualitativo). Es decir, se debe hacer una Business Impact Analysis (BIA) de cara a definir los procesos críticos de negocio y en base a este BIA, el PSP deberá establecer planes de continuidad de negocio que permitan reaccionar en caso de emergencia y medidas mitigatorias, que eviten o disminuyan los efectos adversos de una interrupción en el servicio.
Adicionalmente, será necesario identificar una serie de escenarios (y, según el reglamento delegado, se deben incluir escenarios ‘extremos pero plausibles’) a los que el PSP puede estar expuesto.
Con estas premisas, se definirán planes de recuperación que deberán estar documentados y actualizados en base a las lecciones aprendidas, pruebas, y nuevos riesgos identificados.
La existencia de planes de continuidad de negocio implica, por definición, la necesidad de probarlo (para garantizar que funciona, para que quienes lo tienen que ejecutar se sientan cómodos y conozcan el procedimiento, etc.) y estas directrices indican que se debe testear, al menos, con carácter anual. Los objetivos de las pruebas serán proteger, y, si es necesario, reestablecer la integridad y disponibilidad de las operaciones. Este plan de pruebas también deberá ser actualizado año a año, basado en los resultados previos y las nuevas amenazas.
El plan de pruebas incluirá:
Un conjunto de escenarios adecuado.
Que sea un reto para el personal involucrado.
Procedimientos para verificar la habilidad para responder a dicho escenario.
Además, el PSP deberá monitorizar la eficiencia del plan de continuidad de negocio, de forma documentada, así como analizar los cambios y los resultados de las pruebas.
Un aspecto muy importante que también se incluye en estas directrices es el de asegurar una comunicación eficiente durante una crisis (en tiempo y forma); este plan de comunicación incluirá actores relevantes internos y/o externos, proveedores, etc.
Probar las medidas de seguridad
El PSP deberá contar con un plan de pruebas (testing framework) que permita validar los controles de seguridad implantados; lo suficientemente abierto para soportar nuevas vulnerabilidades y amenazas y deberá asegurarse que se realizan pruebas después de un cambio significativo en la infraestructura.
Además, este framework deberá incluir en su alcance los terminales y dispositivos de pago, así como los dispositivos utilizados para la autenticación de los usuarios y cualquier dispositivo o software que se facilite a los usuarios. Este marco de pruebas debe incluir:
Que las pruebas se ejecutan como parte del proceso de gestión de cambios, para asegurar la robustez y eficiencia de los mismos.
Que las pruebas son llevadas a cabo por personal independiente (con conocimientos y habilidades).
Que deben considerar escaneos de vulnerabilidad y test de penetración adecuados al nivel de riesgo del servicio de pago.
El PSP deberá realizar las pruebas al menos con carácter anual para los servicios de pago considerados como críticos, mientras que los servicios no críticos podrán ser probados cada 3 años, aunque esto se basará en una aproximación basada en el riesgo.
El último control de este punto indica que se deben evaluar los resultados de las pruebas y establecer las medidas de protección que resulten de dicho análisis.
Concienciación y aprendizaje continuo
En este apartado se habla de la concienciación que se debe dar a las partes interesadas; para garantizar una concienciación adecuada, se indica que el PSP debe establecer, identificar y monitorizar las amenazas que puedan afectar al servicio de pago. Serán de ayuda los incidentes que hayan podido ocurrir dentro y fuera de la organización, que deberán ser incluidos como "lecciones clave" para actualizar sus medidas de seguridad.
El PSP establecerá un programa de formación para su staff, de forma que estén preparados para realizar sus tareas, reduciendo errores humanos, robo, fraude o pérdida de información. Además, para las personas en puestos clave, se impartirá formación con carácter anual (o con una frecuencia mayor si es necesario).
También, dentro del plan de concienciación, se buscará educar a los colaboradores, de forma que sepan actuar en casos de riesgo y sepan cómo reportar cualquier actividad inusual o incidente.
Gestionar la relación con el usuario
Además de concienciar a sus empleados, el PSP establecerá e implantará procesos para concienciar a sus usuarios de los riesgos derivados del servicio de pago, así como le facilitará asistencias y guías, que serán actualizadas en base a las nuevas amenazas y vulnerabilidades. El PSP mantendrá al usuario informado sobre actualizaciones de seguridad en relación al servicio de pago.
Si el producto lo permite, el PSP facilitará al usuario la opción de deshabilitar funcionalidades específicas del servicio de pago (por ejemplo, si el servicio de pago ofrece límites, se facilitará al usuario modificar dichos límites).
Además, deberán proveer al usuario de opciones para recibir alertas en caso de que se inicien o se den intentos fallidos de iniciación de pagos, de cara a detectar operaciones fraudulentas.
Por último, el PSP facilitará a los usuarios asistencia en relación a las consultas que puedan surgir, así como en el caso de notificaciones de anomalías o problemas de seguridad; deberá indicar los pasos para obtener esta asistencia.
Desde mi punto de vista, estos controles operativos son muy completos; abordan la seguridad de un modo similar a un sistema de gestión basado en ISO 27001, tomando la gestión de riesgos como base para implantar controles y establecen un sistema de pruebas de cara a incluir un ciclo de mejora continua. Toma en consideración también la necesidad de dar poder a los usuarios y los contempla dentro del ciclo de la seguridad, ya que da responsabilidades de soporte a usuarios a los propios proveedores de servicios de pago, e incluye la posibilidad de que reciban alertas, de forma que puedan notificar al PSP en caso de vulnerabilidad o problemas con sus servicios. Estos controles no incluyen ninguna novedad, si no que han recogido las "best practices" existentes y las han aplicado a los sistemas de pago, intentando de esta forma que los PSP doten de una seguridad robusta a sus sistemas.
Autor: Antonio Martínez Jiménez - CISSP Instructor, ISO 20000 L.A., ISO 27001 L.A., ISO 22301 L.A.
Etiquetas: Directiva 2015/2366., Directiva de Servicios de Pago, Directrices EBA, PSD2
Interés legítimo, el cajón de sastre del RGPD
Desde que entró en vigor el Reglamento General de Protección de Datos (en adelante RGPD), y más aún, desde su aplicabilidad de forma obligatoria el día 25/06/2018, son muchas las dudas, por parte de las empresas y organizaciones, acerca de utilizar como base jurídica para sus tratamientos el denominado “interés legítimo”. Aunque a primera vista puede parecer un tema nuevo, lo cierto es que no se trata de ninguna novedad del RGPD, sino que este concepto ya estaba presente en la anterior Directiva 95/46.
El Reglamento exige que el consentimiento sea inequívoco y se otorgue de forma positiva por parte del interesado, actualmente, en aquellos casos en los cuales no se cuenta con un consentimiento otorgado con tales características y en los que, en principio, no tiene cabida ninguna otra base jurídica se está pretendiendo utilizar el “interés legítimo” como base jurídica legitimadora alternativa. Esta gran indeterminación que suscita el “interés legítimo”, puede conllevar a utilizar esta base jurídica como un cajón de sastre, lo cual puede conllevar una serie de problemas asociados para las empresas y organizaciones que pueden materializarse en forma de denuncias por parte de los interesados y sanciones por parte de la autoridad de control correspondiente.
Este concepto difuso es introducido en el artículo 6.1.f del RGPD, en concreto, cita lo siguiente “el tratamiento es necesario para la satisfacción de intereses legítimos perseguidos por el responsable del tratamiento o por un tercero, siempre que sobre dichos intereses no prevalezcan los intereses o los derechos y libertades fundamentales del interesado que requieran la protección de datos personales, en particular cuando el interesado sea un niño.”; y no debe extenderse su aplicación, de tal forma que resulte la opción de referencia a la que acudir a la hora de legitimar un tratamiento de datos de carácter personal por parte de un responsable del tratamiento. Es preciso realizar un estudio de cada uno de los tratamientos de datos de carácter personal para concretar la base jurídica que mejor se ajuste a dicho tratamiento, y abordar el “interés legítimo” como un fundamento jurídico más, y no pecar por exceso de aplicación del mismo.
Este acto de estudio requiere una ponderación entre el interés del responsable del tratamiento o terceros y los derechos y libertades de los interesados. Esta situación deriva en una ponderación meticulosa, que no consiste solo en una evaluación directa entre ambos intereses, sino que, se deben tener en cuenta diversos factores para tomar la decisión final.
Antes de empezar con dicha evaluación, debe definirse el concepto de interés legítimo, en el ámbito de la protección de datos; es un concepto que abarca un recorrido y significado más amplio que la mera base legítima que permite al responsable del tratamiento llevar a cabo dicho tratamiento. Además, este interés tiene que ser real, concreto, lícito y actual, es decir, no tiene cabida un potencial interés teórico o especulativo, debe estar articulado de una forma clara y concisa, por lo que debe estar lo suficientemente delimitado y definido, para poder ponerlo en contraprestación a los intereses y los derechos fundamentales del interesado y ser realizado de acuerdo con la legislación aplicable en materia de protección de datos o cualquier otra legislación o normativa de aplicación, que no atente contra el orden público, ni sea contrario a los principio generales del Derecho.
No cobra sentido alguno la creación de una lista predefinida y cerrada de intereses legítimos, ya que estos pueden ser infinitos atendiendo al responsable del tratamiento, finalidad, ámbito de la empresa, sector, etc. Sin embargo, el RGPD marca, a modo de ejemplo, algunos supuestos concretos de interés legítimo en los Considerandos contenidos entre el 47 y el 50 ambos incluidos. Algunos de estos ejemplos son:
La mercadotecnia directa.
Garantizar la seguridad de la red y de la información, así como de los servicios proporcionados a través de esos sistemas o redes de información.
Compartir datos personales dentro de un mismo grupo empresarial o entre entidades afiliadas a un mismo organismo central con fines administrativos internos.
La indicación de posibles actos delictivos o amenazas para la seguridad pública, así como la transmisión a la autoridad competente de los datos relacionados con dichos actos delictivos o amenazas para la seguridad pública.
Además, la nueva LOPD-GDD recoge los siguientes supuestos:
El tratamiento de los datos de las personas físicas que presten servicios en una persona jurídica, siempre que se trate de los datos mínimos imprescindibles para su localización profesional y se utilicen para mantener la relación con la persona jurídica.
Por otro lado, el GT29, en su Dictamen 06/2014, de 9 de abril de 2014, sobre el concepto de interés legítimo del responsable del tratamiento de los datos en virtud del artículo 7 de la Directiva 95/46/CE, expone más supuestos considerados como posibles tratamientos que pueden tener como base jurídica la fórmula del “interés legítimo”.
Una vez definido este concepto tan abstracto y presentados algunos ejemplos de tratamientos que pueden tener como base jurídica legitimadora el interés legítimo, la primera consideración a tener en cuenta es responder a la siguiente pregunta "¿Puede el responsable del tratamiento satisfacer su interés legítimo por otros medios menos invasivos?"; para ello se deben realizar los correspondientes análisis de proporcionalidad de las medidas técnicas y organizativas que se pretenden implantar. Si la respuesta a dicha cuestión es en sentido negativo, puede ocurrir que el tratamiento que se desea llevar a cabo sea un tratamiento no legitimado, o bien, que se deba buscar otra base jurídica de las expuestas en el artículo 6 del RGPD para legitimar dicho tratamiento; por otra parte, si la respuesta es afirmativa, es el momento de realizar la ponderación entre los distintos factores definidos anteriormente.
Para llevar a cabo esta ponderación y dilucidar si realmente existe un interés legítimo que pueda ser consistente como base jurídica de un tratamiento, se debe tener en cuenta:
La expectativa de los interesados
El impacto para los interesados
La relación interesados-responsable
Otras cuestiones más específicas del tratamiento específico sobre el cual se lleva a cabo el estudio.
Una vez valorados los criterios anteriores se obtendrá una respuesta provisional, sin tener en cuenta la posibles medidas técnicas y organizativas que el responsable pueda implantar para llevar a cabo el tratamiento, por lo que, como última fase de este análisis, es necesario valorar los riesgos y consecuencias en función de dichas medidas técnicas y organizativas implantadas por el responsable. Algunas de estas medidas pueden ser:
La utilización de técnicas de anonimización de los datos de carácter personal.
Cifrado de datos, que eviten la identificación directa de los mismos.
Formación en materia de seguridad y protección de datos de forma periódica a los empleados.
Procedimiento de backup o rollback que permita recuperar la máxima cantidad de información en el menor tiempo posible ante un incidente.
Facilitar a los interesados información transparente y más amplia que la exigida en el RGPD sobre el tratamiento de datos.
Una vez valorados los criterios anteriores, el responsable dispone de toda la información necesaria para determinar si prevalece su interés legítimo sobre los derechos y libertades de los interesado o no. Si de una forma clara es así, se puede concluir que el tratamiento de datos está legitimado en base a un interés legítimo por parte del responsable, siempre cumpliendo con el resto de las obligaciones expuestas en el RGPD; en caso contrario, el responsable puede tener en cuenta una serie de garantías adicionales para determinar de forma clara si existe interés legítimo o no. Esto requerirá una evaluación ulterior y la implantación de medidas tanto técnicas como organizativas adicionales.
Es recomendable y conviene documentar todo este proceso de determinación del interés legítimo como base jurídica de un tratamiento.
Por último, cabe recordar que con independencia de que se den las condiciones y requisitos necesarios para basar el tratamiento en un interés legítimo, hay que cumplir con el resto de obligación estipuladas en el Reglamento General de Protección de Datos.
Ante la decisión de utilizar el interés legítimo como base legitimadora sin realizar previamente el estudio anteriormente descrito, puedo conllevar que, ante una posible investigación por parte de la autoridad de control correspondiente, en caso de España esta autoridad de control es la Agencia Española de Protección de Datos, se haga muy difícil la defensa del uso de esta base, lo que puede abocar en una sanción económica considerada dada la estructura y clasificación de sanciones recogida en el reglamento. Es por ello, que siempre que se requiera basar un tratamiento en un interés legítimo, es importante realizar la ponderación descrita y dejar todo el proceso documentado justificando cada decisión.
Etiquetas: GDPR, Interés Legítimo, LOPD-GDD, RGPD
En la era actual, en la que prácticamente, a nivel mundial todos nos encontramos conectados a través de internet, redes sociales, smartphones, etc. Nuestros datos de carácter personal, nuestros gustos, nuestra información más íntima, se ha convertido en uno de los mayores negocios y que más dinero mueven en el mundo.
En la edad de oro del Big Data y del Knowledge Discovery, de los datawarehouses y del datamining, resulta bastante sencillo extraer una gran cantidad de información personal de la actividad que realizamos en Internet. La gran mayoría de las personas no son conscientes de la ingente cantidad de datos que hacen públicos o que directamente venden de una forma gratuita a terceras empresas, movidas por una sociedad cada vez más dependientes de las nuevas tecnologías y de su uso no responsable.
La tendencia de las empresas, hoy en día, es recoger la máxima cantidad de datos posibles, aunque no sean necesarios para el trabajo que desempeñan, pero la forma en la cual se mueve el mundo, a mayor cantidad de datos mayor rentabilidad se puede obtener de los mismos.
Es por esto que, con la llegada del nuevo Reglamento Europeo de Protección de Datos, una de las mayores novedades y más llamativas, es la obligación del responsable del tratamiento a minimizar los datos recogidos. A grandes rasgos, esta obligación intenta preservar y proteger los datos de carácter personal de las personas físicas, es decir, empleando la política del “need to know”, evitando que terceras personas se apropien de forma indebida de datos que no les son necesarios para la prestación del servicio que ofertan.
Aunque este término pueda considerarse relativamente nuevo, lo cierto es que ya existía en otros frameworks de seguridad como, por ejemplo, OECD Privacy, en el que se hace referencia al término “Collection Limitation Principle” el cual viene a decir que deben existir límites para la recopilación de datos personales y que cualquier información de este tipo debe obtenerse por medio legales y justos, y que cuando corresponda con el conocimiento o consentimiento del interesado.
El principio de minimización de datos recogido en los artículos 5 y 25 del nuevo Reglamento Europeo, se centra en lo siguiente:
Cantidad de dato recogidos.
Tiempo de retención de los datos.
Número de personas con acceso a los datos.
Perímetro del tratamiento.
Aunque en minoría, cada vez existen más personas, a las cuales les preocupa los abusos que sus datos de carácter personal sufren o pueden sufrir. Esto da lugar a que exista una mayor reticencia por parte de estas personas a nuevos tratamientos o a la cesión de estos datos.
Esta problemática no es buena para ninguna de las dos partes, ni para los usuarios porque dejarían de beneficiarse de ciertos servicios que se han convertido necesarios en su día a día, ni para las empresas que verían reducidos por un lado los servicios que ofertan y, por otro lado, los beneficios que obtienen de los datos de carácter personal de las personas físicas que se los ceden.
Además, con la inclusión del nuevo Reglamento Europeo en materia de Protección de Datos, las sanciones que se derivan del mal uso de los datos de carácter personal se han visto fuertemente endurecidas, lo que supone una vía extra de preocupación para las empresas que tratan este tipo de datos.
Las sanciones más graves, para las empresas que decidan establecer la política de no actuación, serán de hasta 20 millones de euros o el 4% de su facturación anual global, la cifra más alta de las dos. Y las sanciones más leves, podrán llegar hasta los 10 millones de euros o el 2% de su facturación anual global, la cifra más alta de las dos. En concreto, la infracción de la no minimización de los datos de carácter personal se encuadraría dentro del segundo grupo, es decir, dentro del grupo de las sanciones más graves.
La solución a estos problemas de privacidad pasa por encontrar un término medio en el cual las dos partes se encuentren a gusto y confiables.
Por un lado, los usuarios; si las empresas son capaces de proporcionarle la confianza de que tiene total control y conocimiento sobre lo que ocurre con sus datos, éstos no tendrán ningún tipo de inconveniente en cederlos para futuros tratamientos.
Por otro lado, las empresas; que sean capaces de implementar de forma pública y comprobable una política de minimización de datos, conseguirán un ahorro logístico, ya que los datos que no se recogen no exigen gasto alguno y una ventaja competitiva frente a sus rivales, ya que generarán en el usuario una mayor confianza.
Lo que es seguro, es que ambas partes tienen que realizar un proceso de cambio de actitud y de conciencia sobre este tema por el bien de todos.
Etiquetas: GDPR, LOPD
En nuestro día a día, y sobre todo desde la inclusión en nuestra sociedad del mundo IT como una herramienta indispensable en nuestras vidas, realizamos una gran cantidad de acciones que impactan en nuestra privacidad. Cuando nos encontramos caminando podemos ser grabados por las cámaras que regulan el tráfico, cuando entramos en cualquier tienda también existen cámaras de seguridad, cuando navegamos por Internet dejamos una huella gigantesca sobre nuestras preferencias, gustos, datos personales, lugares que visitamos, además, sin pretenderlo, podemos aparecer en fotografías subidas a Internet por terceras personas en sus redes sociales.
Muchas veces, no somos conscientes de la cantidad de datos que compartimos sin pararnos a pensar en quién tratará estos datos, cómo serán usados, si están debidamente almacenados, y lo que es más importante, si una vez compartidos podemos recuperarlos, borrarlos y / o modificarlos.
Por ello, es necesario un reglamento que regule todo este tipo de situaciones en referencia a nuestros datos de carácter personal. En España, desde el año 1999 existe la Ley Orgánica de Protección de Datos (LOPD) y desde el año 2007 su Reglamento de Desarrollo de la Ley de Protección de Datos (RDLOPD).
El 25 de mayo de 2016 entró en vigor el Reglamento General de Protección de Datos (RGPD), aunque su aplicación no se hizo efectiva hasta el 25 de mayo de 2018. En estos dos años, las empresas debían realizar un proceso de adaptación progresivo y continuo a dicho reglamento, en todos aquellos aspectos que sean compatibles con la normativa vigente.
La LOPD es de las más tuitivas de Europa, por lo que el RGPD no introduce tantas diferencias como en otros países, aunque existen una serie de obligaciones adicionales a cumplir a partir del 25 de mayo de 2018.
¿En qué afecta el RGPD a la LOPD? ¿Qué hay de nuevo en este reglamento? A continuación, vamos a ver las principales novedades del RGPD respecto a la LOPD y su reglamento de desarrollo.
LOPD: El consentimiento del interesado es “toda manifestación de voluntad libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos personales que le conciernen”
RGPD: Añade que para considerar que el consentimiento es inequívoco, según el artículo 32 del RGPD, se requerirá una acción positiva que manifieste su conformidad o una declaración del interesado. Ya no cabe el consentimiento tácito que en ocasiones permitía la LOPD, sobre todo en Internet. Por ejemplo, ya no se entenderá otorgado el consentimiento por la simple navegación en una página web.
Además, se establecen condiciones específicas para obtener el consentimiento de los menores.
LOPD: Los derechos marcados por la LOPD son los siguiente:
RGPD: Además de los derechos incluidos en la LOPD, el RGPD incluye los siguientes derechos:
Derecho de supresión: permite al interesado, en una serie de casos, obtener sin dilación indebida del responsable del tratamiento la supresión de los datos personales que le conciernan. No es más que una manifestación de los tradicionales derechos de oposición y cancelación, pero reforzado, y garantizado también en el entorno de Internet.
Derecho de limitación del tratamiento: consiste en reconocer la potestad del interesado de solicitar y obtener del responsable del tratamiento o fichero, una limitación del tratamiento de sus datos personales cuando concurran los siguientes supuestos:
Derecho de portabilidad: permite al interesado recibir los datos personales que le incumban, que haya facilitado a un responsable del tratamiento por medios automatizados, en un formato estructurado, de uso común y lectura mecánica, y transmitidos a otro responsable del tratamiento sin que lo pueda impedir el primer responsable.
LOPD: Actualmente, la LOPD establece que se debe informar, en todo proceso de recogida de datos de carácter personal, de la finalidad, de la existencia de un fichero, de la obligación o no de la entrega y sus consecuencias, de los derechos del interesado y la identidad del responsable. Además, si el responsable ha obtenido los datos de terceros, dispone de un plazo de 3 meses para informar al interesado, indicando siempre la procedencia de los datos.
RGPD: El nuevo reglamento europeo refuerza esta obligación, introduciendo nuevos aspectos que deben ser comunicados al interesado. Debe informarse, de la base jurídica del tratamiento, el periodo de conservación de los datos de carácter personal y que los interesados pueden reclamar ante las autoridades de protección de datos, si consideran que existe un problema con la forma en la cual están tratando sus datos. Además, si la información se ha obtenido de terceros, deberá informarse al interesado en el plazo máximo de un mes.
Comunicación de fallos a la autoridad de protección de datos
LOPD: La actual legislación no regula esta casuística.
RGPD: El nuevo reglamento europeo incorpora la obligación del responsable del tratamiento de notificar cualquier violación de seguridad de los datos de carácter personal, tanto a la autoridad de protección de datos, como al interesado.
RGPD: Establece la obligación de realizar una evaluación de impacto para aquellas empresas que realicen tratamientos de datos que puedan implicar un alto riesgo para los derechos y libertades de las personas físicas. En este análisis debe evaluarse el origen, la naturaleza, la particularidad y la gravedad de dicho riesgo.
LOPD: Establece en su RDLOPD una serie de medidas de seguridad a aplicar dependiendo de la clasificación de los datos de carácter personal que contenga, básicos, medios o altos.
RGPD: A diferencia de la LOPD, el RGPD no establece un listado de medidas de seguridad, sólo indica que las medidas de seguridad que se adopten deben ser apropiadas en función del riesgo. El desglose de las medidas de la LOPD, deberían bastar para cumplir con las obligaciones de protección de datos, por lo que dicho listado puede servir de manera orientativa a las empresas para medir su nivel de cumplimiento.
RGPD: Las empresas u organizaciones que habitualmente realicen tratamiento de datos de riesgo para la los derechos y libertades de los interesados, o traten datos especialmente protegidos, o relativos a condenas e infracciones penales, deberán tener un registro de las actividades de tratamiento efectuadas bajo su responsabilidad. Este registro interno, el cual tienen que realizar tanto responsables como encargas del tratamiento, deberá realizarse por escrito, y contener información detallada acerca de cada uno de los tratamientos de datos que realicen.
RGPD: Nace la figura de Delegado de Protección de Datos, cuyas funciones son las siguientes:
Informar y asesorar al responsable del tratamiento de datos de carácter personal de las obligaciones que debe cumplir para alinearse con el reglamento general.
Supervisar la aplicación de las medidas de seguridad por el encargado del tratamiento en materia de protección de datos de carácter personal.
Supervisar la documentación, notificación y comunicación de las violaciones de datos de carácter personal.
Supervisar la respuesta a las solicitudes de la autoridad de protección de datos y cooperar con ella por solicitud de la misma o por iniciativa propia.
Ejercer de punto de contacto con la autoridad de protección de datos.
Por todos estos cambios, es conveniente que las empresas revisen su estructura interna para asegurar que tiene los mecanismos y medidas de seguridad correspondientes adecuadas para cumplir con el nuevo reglamento europeo. Además, de que tienen todo lo necesario para que el delegado de protección de datos pueda cumplir con su función adecuadamente, y que todos los empleados conocen los protocolos de actuación en materia de protección de datos.
En definitiva y sobre todo, es importante por un lado, adecuar las cláusulas de información al interesado y la recogida del consentimiento para que se realice conforme al nuevo reglamento y se haga efectiva sobre una base legítima válida y adecuada, y por otro lado, revisar todos los procedimientos de protección de datos y proveer a los sistemas que tratan los datos de carácter personal, de una capa de seguridad adecuada para proteger dichos datos y garantizar la seguridad de los mismos.
Etiquetas: Derecho de supresión, DPO, LOPD, RGPD, Tratamiento de datos
Bancos, Fintech…¿hasta dónde llega PSD2?
Directiva de Servicios de Pago 2 y antecedentes
Desde hace algunos meses todos venimos escuchando hablar de la Directiva 2015/2366, mejor conocida como PSD2 (Payment Services Directive 2). Mucho se ha hablado de esta directiva; de la obligación de los bancos de disponer formas de consultar sus servicios para minoristas (probablemente en forma de APIs). Sin embargo, esta directiva tiene un ámbito de aplicación y un alcance mucho más extendido.
La Unión Europea ha publicado varias normativas en relación a la seguridad de los pagos. Por ejemplo, en 2007, la Unión Europea creó la primera Directiva de Servicios de Pago, que sentó precedente para posteriormente generar el Reglamento SEPA, el cual definía la Single Euro Payments Area (o en castellano, Zona Única de Pagos en Euros).
Antes de continuar entrando en materia es necesario tener claro algunos conceptos:
El dinero electrónico se entiende como el valor monetario que cumple las siguientes características:
Se almacena en un soporte electrónico.
Es emitido al recibir fondos de un importe cuyo valor no será inferior al valor monetario emitido.
Es aceptado como medio de pago por empresas diferentes al emisor.
¿Qué son los servicios de pago?
Probablemente uno de los conceptos más importantes de toda la Directiva. Estos servicios de Pago se encuentran definidos en al Anexo I y son:
Servicios que permitan el depósito de efectivo en una cuenta de pago y todas las operaciones necesarias para la gestión de una cuenta de pago.
Servicios que permitan la retirada de efectivo de una cuenta de pago y todas las operaciones necesarias para la gestión de una cuenta de pago.
Ejecución de operaciones de pago, incluida la transferencia de fondos, a través de una cuenta de pago en el proveedor de servicios de pago del usuario u otro proveedor de servicios de pago:
Ejecución de adeudos domiciliados, incluidos los adeudos domiciliados no recurrentes.
Ejecución de operaciones de pago mediante tarjeta de pago o dispositivo similar.
Ejecución de transferencias, incluidas las órdenes permanentes.
Ejecución de operaciones de pago cuando los fondos estén cubiertos por una línea de crédito abierta para un usuario de servicios de pago:
Como vemos, son muchos los casos por los que un proveedor de servicios de pago se ve afectado por la presente directiva, pero de aquí surge otra pregunta: ¿qué es una cuenta de pago?
Una cuenta de pago no deja de ser cualquier cuenta sobre la que un usuario puede hacer un depósito o una retirada de efectivo, como sería una cuenta corriente de un banco. Es cierto que no hay una definición estandarizada de lo que es una cuenta de pago, y, además, la Directiva presenta cierta ambigüedad con el propósito de englobar posibles cambios y avances tecnológicos futuros, haciendo que surjan dudas en relación al alcance de la misma.
Una de las descripciones más ampliamente aceptadas es la que da la autoridad financiera del Reino Unido (Financial Conduct Authority, FCA). Según la FCA, para establecer si una cuenta puede ser considerada de pago se deben considerar:
El propósito para el que ha sido creada la cuenta.
Las funcionalidades que ofrezca la propia cuenta (como, por ejemplo, si permite realizar o no transferencias).
Restricciones de la propia cuenta (si únicamente pueden realizarse retiradas de dinero en un momento dato, por ejemplo).
Que la cuenta tenga limitación en la retirada y depósito de dinero siendo necesaria la intervención o acuerdo de un proveedor de servicios.
La finalidad con la que el propio usuario utiliza la cuenta.
Teniendo todo esto en consideración, ejemplos de cuenta de pago se considerarían, además de las ya mencionadas cuentas corrientes, las cuentas de dinero electrónico, las cuentas de las tarjetas de crédito o las cuentas de ahorro flexibles.
Pero ¿a quién afecta PSD2? Los Proveedores de servicios de pago
Este año ha entrado en vigor la directiva PSD2 que, a raíz de los progresos en la integración de los pagos minoristas en la Unión Europea, sirve como actualización y revisión del marco jurídico para englobar los nuevos servicios y productos ofertados. También sirve para detallar y clarificar artículos que en directivas anteriores eran demasiado ambiguos o generalistas.
Teniendo esto en consideración, la norma establece una serie de directrices en materia de seguridad y los requisitos para poder establecerse como proveedor de servicios de pago, además de definir nuevos actores en base a los nuevos servicios ofertados por algunas organizaciones, pero ¿qué es un proveedor de servicios de pago?
Para contestar a esta pregunta vamos a ver las diferentes categorías para los proveedores de servicio de pagos que vienen detalladas en el artículo 1 de la presente directiva, y en las que se incluyen:
Las entidades de crédito, tal como se definen en el Reglamento (UE) 575/2013, artículo 4, apartado 1, punto 1: "una empresa cuya actividad consista en recibir del público depósitos y otros fondos reembolsables y en conceder créditos por cuenta propia". Se incluyen también las sucursales de dicha entidad, siempre y cuando se encuentren dentro del territorio de la Unión. Los bancos son un ejemplo de proveedor de servicios de pago que entran en esta categoría.
Entidades de dinero electrónico: Estas entidades se definen en la Directiva 2009/110/CE, artículo 2, punto 1, "toda persona jurídica a la cual se haya otorgado autorización de conformidad con el título II, para emitir dinero electrónico". En el título II de esta directiva se describen las condiciones para realizar actividades con dinero electrónico. En caso de disponer de oficinas en territorio de la Unión, éstas también se verán afectadas por PSD2.
Paypal sería el ejemplo más conocido de una entidad que trabaja con moneda electrónica y que realiza transacciones a través de "dinero virtual".
Instituciones de giro postal capaces de prestar servicios de pago. Es decir, servicios de pago realizado por un servicio de correos. En España sería la propio Correos, o bien instituciones como Western Union.
El Banco Central Europeo y los bancos centrales nacionales cuando no actúen en su condición de autoridad monetaria. Esto será para los servicios de pago que ofrezcan estas entidades, más allá de su rol como autoridad monetaria.
Los estados miembros y sus autoridades regionales y locales cuando no actúen en su condición de autoridades públicas. Similar al caso anterior; cuando las autoridades ofrezcan servicios de pago y no estén relacionados con su rol como autoridad monetaria, deberán cumplir con PSD2.
Entidades de pago. En este apartado recaerán la mayoría de los proveedores de servicios de pago. Encontramos la definición de este concepto en el artículo 4, que indica: "una persona jurídica a la cual se haya otorgado autorización, de conformidad con el artículo 11, para prestar y ejecutar servicios de pago en toda la Unión". El artículo 11 incluye requisitos para conceder autorización a un proveedor, por lo que lo que nos interesa en este momento es el concepto de "Servicios de pago".
Uno de los nuevos actores definidos por la Directiva viene derivado del servicio de “iniciación de pagos”. Se trata de servicios online a través de los cuales un usuario inicia una orden de pago en la cual se accede a una cuenta de pago para iniciar una transferencia de fondos. Para más información, podemos consultar el FAQ del 12 de enero de 2018 de la Comisión Europea, en la que se indica que los proveedores de servicios de iniciación de pagos "ayudan a los consumidores a hacer transferencias de crédito online e informan al comercio de forma inmediata de la iniciación del pago, permitiendo el envío de los bienes o el acceso inmediato al servicio contratado online". Al indicar que se trata de transferencias de crédito online, se incluye la posibilidad de realizar pagos a través de internet sin necesidad de una tarjeta de crédito, siendo únicamente necesaria una cuenta de pago; aunque en España no estamos muy habituados a esta operativa, sí se ve en algunos países europeos.
El último actor que se define en esta nueva PSD2, es el de "Proveedor de servicios de información de cuentas" que se define como un servicio online que da información agregada sobre una o varias cuentas de pago en las que es titular el usuario del servicio en otro proveedor o proveedores de pago. Un ejemplo de este tipo de actores sería la empresa española Fintonic.
Estos son los actores sobre quienes aplica la Directiva PSD2. No obstante, debemos considerar que estamos ante una directiva europea, por lo que el ámbito de aplicación también se verá impactado por diversas características, que se definen en el artículo 2. En este artículo, en el punto 1, se define que el alcance de PSD2 aplicará a los servicios de pago prestados dentro de la Unión, cosa que ya definía la Directiva de 2007. Sin embargo, en los subsiguientes puntos se amplía el alcance, incluyendo:
Operaciones de pago en monedas diferentes de las utilizadas en la Unión, cuando tanto emisor como receptor se encuentran establecidos dentro de la Unión.
Operaciones de pago donde el emisor o el receptor estén en la Unión (basta con que uno de los proveedores de servicio esté en la Unión), independientemente de la moneda utilizada.
A este aspecto cabe hacer dos aclaraciones, la primera es que la Directiva limita el alcance en estos escenarios: “Respecto de aquellas partes de la operación de pago que se lleven a cabo en la Unión”, dejando claro que es posible que los proveedores de servicios de pago no puedan cumplir sus obligaciones en relación a transacciones que tienen lugar fuera de la Unión.
También indicar que hay varios artículos (como el 45 o el 52) dentro de la Directiva que sirven como excepciones a los casos aquí listados. Estas excepciones darían para otro artículo, por lo que no las trataremos aquí.
Otro de los aspectos que quiero destacar de esta nueva Directiva es el de la transparencia. Siguiendo los caminos marcados por otras regulaciones y directivas, PSD2 también es muy explícita exigiendo requisitos de transparencia. Lo podemos ver en al artículo 1, punto 2 “La presente Directiva establece asimismo normas en materia de los requisitos de transparencia”, donde ya se introduce esta necesidad y para la que se profundiza mucho más en el Título III “Transparencia de las Condiciones y Requisitos de Información Aplicables a los Servicios de Pago” (artículos 38-60). Este título se subdivide en cuatro capítulos, de los cuales me centraré en los capítulos 2 y 3. Estos capítulos son muy similares entre sí, y describen los derechos de deberes de todos los actores involucrados en los pagos; pagos singulares en el capítulo 2 y contratos marco en el capítulo 3.
En el artículo 44 (capítulo 2), por ejemplo, vemos cierto alineamiento con el RGPD, cuando se indica que el proveedor de servicios de pago estará “obligado a poner a disposición del usuario de servicios de pago, de un modo fácilmente accesible para él, la información y las condiciones … en relación con sus propios servicios, antes de que el usuario quede vinculado por cualquier contrato u oferta”, añadiendo además “La información y las condiciones estarán redactadas en términos fácilmente comprensibles, de manera clara y legible”, de manera que el usuario tenga claros sus derechos y obligaciones antes de utilizar el servicio cuando se trata de una operación de pago.
Continuando con este capítulo, por su parte, el artículo 45 da más detalle sobre la información que se requiere facilitar a los usuarios, mientras que los artículos 46-49 reflejan la información a aportar por el proveedor de servicios de pago a los diferentes actores durante y tras la ejecución de la operación.
En relación al capítulo 3, la estructura es similar al capítulo 2, solo que en este caso hablamos de contratos marco, obligando (artículo 51) a facilitar al usuario en un ‘soporte duradero’ la información y condiciones del servicio, detalladas en el artículo 52, que además recoge cláusulas sobre los gastos, tipos de interés, cambios y ceses de los contratos.
Mencionar también el artículo 40, donde se indica que el proveedor de servicios de pago no podrá cobrar al usuario por el suministro de la información, aunque se podrá cobrar por facilitar información adicional a través de canales de comunicación especificados en un contrato marco, siendo siempre un precio razonable y acorde a los costes efectivos.
España aún no ha publicado una ley que trasponga la Directiva 2015/2366 (a diciembre de 2018), aunque ya se dispone de un anteproyecto que se puede consultar en la web del Ministerio de Economía y Empresa, bastante alineado, aunque con algunos cambios estructurales; tendremos que esperar para ver cómo queda la ley finalmente.
En resumen, esta directiva amplía los límites existentes en materia de servicios de pago, e incluye los nuevos roles para adaptarse a los cambios tecnológicos y nuevos actores que han surgido en los últimos años, mejorando los derechos de los ciudadanos y aumentando las responsabilidades de las compañías.
Sin duda, la mayor carga de trabajo esté en los propios bancos, ya que facilitar el acceso a su información supone, además del gasto en el desarrollo de la API y el gasto en seguridad consecuente (lo veremos en otro artículo, pero también se recogen necesidades en materia de continuidad de negocio y doble factor de autenticación), pierden su ‘monopolio’ en relación a esta información. Desde mi punto de vista, sin duda son los principales ‘perdedores’ de esta nueva directiva, aunque considero que también puede verse como una gran oportunidad de negocio, ya que al facilitar el acceso a la información de terceros tendrán una gran variedad de canales a través de los que ofrecer sus servicios.
Por su parte, los proveedores de servicios de pago pasarán a estar más regulados. A su favor tienen que para ellos será más fácil y transparente acceder a la información de los bancos (ya sea para acceder a información bancaria en el caso proveedores que se hagan consolidación de información como para los iniciadores de pago, que tendrán que consultar el saldo del usuario), pero, por el contrario, tendrán gran cantidad de obligaciones, siendo necesario establecerse como proveedor regulado, demostrar la disponibilidad de fondos propios (aunque esto no será necesario para todos los proveedores de servicios) y garantizar la seguridad a través de ciertos requerimientos técnicos incluidos en los reglamentos delegados.
¿Los grandes beneficiarios? Los usuarios, sin ninguna duda. Ganan en derechos, al tener la información fácilmente accesible; ganan en seguridad, pues su información debe ser tratada siguiendo ciertas pautas que están obligados a cumplir estos proveedores de servicio y ganan en el servicio prestado, ya que, al poder facilitar el acceso a su información a terceros, podrán elegir entre gran cantidad de proveedores que ofrezcan servicios similares y elegir el que más se adecúe a sus necesidades.
Guía PSD2 del European Banking Federation: https://www.betaalvereniging.nl/wp-content/uploads/EBF_PSD2_guidance_september2016.pdf
FAQ Payment Services de la Financial Conduct Authority: https://www.handbook.fca.org.uk/handbook/PERG/15/3.html?date=2016-02-03
FAQ PSD2 de la Comisión Europea: http://europa.eu/rapid/press-release_MEMO-15-5793_en.htm
Etiquetas: Directiva 2015/2366, Directiva de Servicios de Pago, PSD2
Etiquetas: CyberCamp 2018, Eventos, Hackathon, INCIBE, Magneto, OSINT, Tinfoleak
En términos de aplicabilidad de este reglamento, el elemento clave que lo define es el concepto de datos personales. Según la Comisión Europea, los datos personales son "toda información sobre una persona física identificada o identificable ("el interesado")". Por otro lado, complementa: "se considerará persona física identificable toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un identificador, como por ejemplo un nombre, un número de identificación, datos de localización, un identificador en línea o uno o varios elementos propios de la identidad física, fisiológica, genética, psíquica, económica, cultural o social de dicha persona". Algunos ejemplos de datos personales son:
Precisamente, es en este último punto en el cual GDPR converge con el estándar PCI DSS: La protección de los datos de tarjetas de pago vinculadas con ciudadanos europeos. No obstante, son documentos diferentes pero que pueden ser empleados indistintamente como complemento para lograr el cumplimiento de uno o del otro y no son excluyentes. De hecho, Jeremy King, Director Internacional del PCI SSC para Europa, comentó en una entrevista:
"La gente acude a mí y me dice: '¿Cómo logro el cumplimiento de GDPR?' ... Comience con PCI DSS".
A continuación, se presenta una tabla comparativa entre GDPR y PCI DSS, que le permitirá al lector establecer las pautas básicas para el establecimiento de programas de alineación entre estos dos marcos normativos.
RGPD/GDPR PCI DSS
Fecha efectiva de cumplimiento 25 de mayo de 2018 (artículo 99). La primera versión de PCI DSS se publicó el 14 de diciembre de 2004. Se realizan actualizaciones de versiones de forma periódica.
No se contemplan derechos específicos de los interesados sobre los datos de tarjetas de pago obtenidos en función del negocio.
Responsable del tratamiento ("data controller"): Entidades o individuos que necesitan procesar datos personales para su negocio. Ellos determinan los propósitos y la manera en que se procesan los datos personales.
Encargado del tratamiento ("data processor"): Persona física o jurídica, autoridad pública, servicio u otro organismo que trate datos personales por cuenta del responsable del tratamiento.
En función de la cantidad anual de transacciones con tarjetas realizadas y del tipo de entidad (comercio o proveedor de servicio), se requiere:
La ejecución de una auditoría anual en sitio realizada por auditores certificados (QSA), o
Rellenar un cuestionario de autoevaluación anual (SAQ).
Controles de seguridad a implementar La aplicabilidad de medidas técnicas y organizativas para demostrar la conformidad del tratamiento con el Reglamento son discrecionales (no se describen de forma explícita) y deben ser elegidas por el Responsable o el Encargado del tratamiento (artículos 25 y 32) mediante el concepto de protección de los datos desde el diseño y por defecto. Las medidas técnicas, físicas y administrativas a implementar se describen a lo largo de los 12 requisitos del estándar. Se trata de controles de seguridad a bajo nivel definidos explícitamente. También se incluyen controles alternativos o compensatorios, en caso de que la implementación del control descrito en el estándar no pueda ser cubierta debido a una justificación técnica o de negocio.
Técnicas para la protección de los datos afectados
Valores hash de una vía basados en criptografía sólida.
Tokens y ensambladores de índices.
Criptografía sólida con procesos y procedimientos asociados para la administración de claves.
Se requiere definir un rol de responsable de cumplimiento de PCI DSS si la entidad afectada es un proveedor de servicio (req. 12.4.1) o una entidad designada (según el anexo A3 – A3.1.1). Para los demás comercios es solo una recomendación.
Reporte de brechas de seguridad (incidentes) En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente de conformidad con el artículo 55 sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella, a menos que sea improbable que dicha violación de la seguridad constituya un riesgo para los derechos y las libertades de las personas físicas. Si la notificación a la autoridad de control no tiene lugar en el plazo de 72 horas, deberá ir acompañada de indicación de los motivos de la dilación (artículo 33). El requisito 12.10 requiere la definición de un plan de respuesta a incidentes, su revisión y prueba anual, designación de personal y formación al mismo y un plan de mejora contínua. El reporte de incidentes se debe dirigir directamente a las marcas, de acuerdo con los procedimientos y tiempos estipulados por cada una de estas entidades.
Responsable de la investigación de incidentes Las tareas de investigación de incidentes relacionados con datos personales recaen en la autoridad de control. Dependiendo de la magnitud del incidente, las marcas pueden exigirle a la entidad afectada la contratación de los servicios de un PCI Forensic Investigator (PFI). Los PFI son empresas homologadas y listadas en el sitio web del PCI SSC encargadas de la investigación, generación de reportes y soporte a la entidad afectada en caso de un incidente.
Sanciones por incumplimiento Se sancionará con multas administrativas de 20.000.000 EUR como máximo o, tratándose de una empresa, de una cuantía equivalente al 4 % como máximo del volumen de negocio total anual global del ejercicio financiero anterior, optándose por la de mayor cuantía (artículo 83). Las multas por incumplimiento son establecidas de forma unilateral por las marcas de pago en función del incidente. No existen tablas públicas con estos datos.
Ya sea que se necesite implementar GDPR en un entorno alineado con PCI DSS o viceversa, el primer paso consistirá en la ejecución de un análisis diferencial de cumplimiento ("gap analysis") para detectar incumplimientos y definir acciones correctivas.
Por definición, el dato del PAN (Primary Account Number – Número Primario de Cuenta) y los demás datos vinculados con tarjetas de pago (nombre del titular, datos completos de la banda magnética, etc.) son considerados como información personal de identificación ("Personally Identifiable Information" - PII), ya que que pueden usarse para identificar, contactar o localizar a una persona en concreto, o pueden usarse, junto a otras fuentes de información, para hacerlo.
Autor: David Eduardo Acosta CISSP|I, CISM, CISA, CRISC, C|EH, C|HFI Instructor, OPST, PCI SSC QSA for DSS/P2PE/3DS/TSP Dpto. Consultoría
Etiquetas: Datos de tarjeta, Datos Personales, GDPR, PCI DSS