Cumplimiento con el RGPD: una inmersión completa en sus datos sensibles de SAP

Nuevamente, hola a todos, y gracias por asistir a nuestro webinar sobre cómo asegurar la conformidad con el RGPD y demás normativas de privacidad de datos. Antes de comenzar, le informamos que este webinar está siendo grabado y que les llegará la grabación por correo electrónico. Además, los micrófonos están silenciados durante toda la sesión. Si tienen alguna pregunta, lo pueden dejar en el apartado de preguntas de GoToWebinar. Y si nos queda tiempo al final, les responderemos las a las preguntas. De lo contrario, se les mandará las respuestas por correo. Andrea, si puedes pasar a la siguiente diapositiva, por favor. Me presento, yo soy Stephanie Gromonte, y formo parte del equipo de marketing de Epius Labs. Hoy me acompaña Andrea García Ropero, consultora de servicios SAP en nuestro equipo. Andrea es licenciada en bioingeniería, pero decidió reorientar su carrera hacia hacia SAP hace unos años, momento en el que se incorporó a Epius Labs, y ella es experta en temas de HCM y privacidad de datos. Antes de darle paso a Andrea, les cuento brevemente quiénes somos para los que no nos conocen. Epius Labs es una empresa internacional de soluciones de software y servicios gestionados. Contamos con más de mil ochocientos clientes en todo el mundo, y tenemos presencia en cincuenta y cinco países. Además de que ofrecemos soporte en varios idiomas, incluido el español. Formamos parte del Group Elephant, y destinamos el uno por ciento de nuestra facturación anual al programa ERP, elefantes rinocerontes y personas, la cual es una organización sin ánimo de lucro. Ahora que ya saben quiénes somos, les cuento lo que tenemos preparado para hoy. Vamos a hablar sobre la conformidad con el RGPD en sistemas SAP y los retos que enfrentan las organizaciones para gestionar datos personales de manera segura en a lo largo alrededor de todo el mundo, pero en concreto en países de habla hispana. Andrea presentará los principales riesgos y obligaciones que impone el reglamento, Y veremos cómo la suite de privacidad de datos de Push Labs le puede ayudar a identificar, a minimizar y auditar información sensible en SAP. También compartiremos uno de nuestros casos de éxito para ilustrar cómo una empresa, en concreto Nestlé, logró cumplir con los requisitos de RGPD de forma eficiente, reduciendo riesgos y simplificando la gestión de datos. Esto es todo por la introducción, y Andrea te paso la palabra. Gracias, Steffen. Pues, como ha dicho Shandoni, vamos a hablar básicamente sobre las nuevas leyes de privacidad que está viendo y la importancia sobre que la la importancia que hay en cumplirlas y en cumplir con estos requerimientos de las leyes de protección de datos. Entonces, primero vamos a hablar de cómo han influido las leyes sobre la privacidad en las empresas. El el primer impacto y el más significativo siempre va a ser el financiero. Como podemos ver, en España han habido varias multas de incluso varios millones de stand libers, pero también serían euros, de varios millones de euros en en diferentes empresas varios puntos. Y como podéis ver, incluso hay, no tiene que ser incluso una empresa, sino que también podría ser en individuos. O sea, cualquier persona o empresa que guarde datos estaría obligado a cumplir con estas leyes. Y pasa lo mismo para Latinoamérica. Dos mil veinticuatro, dos mil veinticinco, básicamente, sobre todo en este sector, es la la nueva era la era de las nuevas leyes, ya que están doliendo muchas leyes y y se están actualizando conforme a las que había antes, sobre todo en países como México y Chile, que se han se han hecho legislaciones mucho más modernas reemplazando las viejas normas. Se ha de un enfoque en la inteligencia artificial y en la responsabilidad, ya que las nuevas leyes ponen foco en el uso de la de la inteligencia artificial. Las autoridades tienen más poder en este sentido, ya que los reguladores con las leyes más antiguas, como Colombia o Perú, están intensificando la legislación y la fiscalización y sancionando a las empresas. Y también la regulación ya no es solo un, ya no es solo teoría, sino que ahora se está pasando realmente a la práctica, ya que se se exige un cumplimiento real, transformando la privacidad de datos en un riesgo y una oportunidad también para generar confianza en el cliente. Las sanciones han han evolucionado significativamente. Por ejemplo, en México, las sanciones van de de varios de, o sea, van por montos y se han se han llegado a sancionar hasta cuarenta y seis millones de pesos mexicanos. En Chile, por ejemplo, se calculan por unidades tributarias, es decir, pues serían de dos mil hasta diez mil o veinte mil unidades tributarias mensuales. En Argentina, las sanciones también han llegado a ser hasta una una un cierre temporal de bancos. En Colombia, por ejemplo, va por salarios mensuales, en Brasil por la facturación de la empresa en el en ese año. Entonces, son leyes proporcionalmente calculadas al al al valor que tiene esa empresa, pero siempre van a afectar significativamente al financiamiento y a la, o a la financiación de la empresa. Además, hay otra cosa a tener en cuenta que no es solo el el factor monetario, sino que también tenemos que tener en cuenta la, ¿cómo se dice? La la reputación, ¿no? Porque hoy en día las las leyes de GDPR están muy al día, todo el mundo sabe o la mayoría de gente conoce sus derechos, entonces, que una empresa sea sancionada con una multa, o sea, con una multa por haber por no haber respetado estas leyes, pues puede suponer una mala reputación. Entonces, hemos hecho una pregunta a nuestros clientes, y es que llevo quince años utilizando SAP. ¿Cuánta información personal identificable he acumulado? Y esto se puede ver claramente en este en este gráfico, ya que, por ejemplo, nosotros podemos tener un empleado en nuestro sistema SAP, ¿no? Este empleado, si si genera facturación, es decir, si, por ejemplo, viaja, lo lo vamos a, probablemente, le vamos a crear un registro como vendor, ¿no? Si, por ejemplo, se usa Sfore, probablemente, este mismo empleado y vendor vaya a existir como un business partner, y además, también podría existir como customer si nos presta un servicio. Esto significa que estos mismos datos se replican a lo largo de un set de tabla, y esta información personal identificable está replicada en muchísimas tablas en el sistema, y toda esta información, al final, es información sensible que debería cuidarse. Entonces, como podemos ver, y como todos sabemos, en SAP todos los datos están conectados. Esto es parecido al al diagrama que acabamos de ver, pero, como podemos ver, pues un empleado mismo va a ser también un business partner, a la vez también va a ser un customer, y a la vez va a tener varias direcciones que van a existir según, pues, sea el business partner o, por ejemplo, tiene varias direcciones por alguna razón, y y así pasaría lo mismo con los mails, con los teléfonos, con los datos bancarios, por ejemplo. Entonces, hay que tener muchas cosas en cuenta. Y ahora vamos a hablar sobre cómo podemos, qué camino debemos seguir para asegurar este cumplimiento, ¿no? En primer lugar, y lo más importante, es hacer una evaluación del impacte del impacto y los riesgos, es decir, identificar los riesgos de cada empresa. Por ejemplo, si tenemos una empresa que se dedica a la telefonía y tenemos personas que están constantemente cogiendo llamadas y cogiendo datos de cogiendo datos de personas que sus datos son sensibles, pues eso, por ejemplo, sería un riesgo y hay que tenerlo en cuenta. Luego, una vez hemos encontrado nuestro el impacto que tenemos y estos riesgos, tenemos que buscar y mapearnos esos datos PI. PI significa, en inglés sería información personal identificable, y serían estos datos que pueden reconocer a una persona, y habría que buscarlos, saber dónde están y poder mapearlos. Luego es también importante, y todos sabemos, el tema de los roles de las autorizaciones y revisar los accesos, es decir, tener claro quién tiene acceso a qué y que las personas que tengan acceso a los datos más sensibles sean personas que en las que se pueda confiar o en las que haya un contrato que que esté firmado conforme no pueden no pueden revelar esos datos, por ejemplo. Luego habría que depurar el backlog de producción, es decir, producción al final del sistema que nunca se van a a refrescar. Al final tenemos muchos datos históricos que no nos hacen pantalla en el sistema. Entonces, pues eso también sería una parte que también nuestros productos pueden cubrir. Luego, hay que gestionar los datos sensibles en las copias de producción, es decir, por ejemplo, en entornos de preproducción de spambots de calidad, que es normalmente se hacen refrescos desde producción, pues esos datos al final, si se pasan a calidad, pues habría que enmascararlos para poder ser usados como entornos de texto. Luego, tenemos que tener un proceso empresarial para solicitudes de acceso de los interesados, de que si una persona está interesada en saber qué datos guarda esa empresa sobre él, tendríamos que tener un proceso en el que podamos podamos buscar estos datos y encontrarlos. Es exactamente poder procesar solicitudes individuales de la iluminación de datos, es decir, no solo encontrarlos, sino poder borrarlos si si nos lo piden. Es decir, identificar proactivamente los datos, es decir, no solo esperar a que el usuario nos nos avise de que quiere borrar sus datos, sino que nosotros ya tenemos que tener un proceso de, si es empleado hace más de diez años que ya no está en la empresa, por ejemplo, pues debería, sus datos deberían ser borrados. No tenemos que esperar a que este empleado conozca las leyes y sepa que esos datos no tienen por qué estar ahí. Y, por último, tenemos que tener auditorías y revisiones continuas para asegurar que este camino, este, es como un círculo y se vaya cumpliendo. Estas son las preguntas que hemos hecho y y los desafíos que hay en términos de cumplimiento y seguridad, al final, nuestros clientes son reducir la cantidad de datos copiados fuera de producción, identificar y mapear los datos en su instancia SAP, identificar y listar los datos que hay de un sujeto en un PDF, eliminar los datos personales en producción cuando eso como observación ya no esté justificada, y eliminar los datos personales reales de los sistemas de prueba y desarrollo. Y también mucha gente tiene todos los puntos anteriores. Esta es nuestras, lo que llamamos la suite de privacidad, y son, básicamente, los cuatro productos que tenemos para poder cumplir con estas legislaciones. En primer lugar, tenemos data retain y data datat, que lo que va a hacer, por ejemplo, data retain es que va a gestionar los períodos de conservación de datos. Y en cuanto un empleado, un empleado, digo empleado como ejemplo, pero cuando en cuanto un empleado no cumpla esos períodos de conservación, se va a enviar a la cola de redacción. La redacción es que se van a modificar datos históricos en producción, es decir, vamos a poder encontrar los datos que ya no necesitan ser guardados en producción proactivamente, y luego los vamos a poder enmascarar, borrar, no se borran porque siempre se conservan, pero se enmascaran. Y luego tenemos data secure, que sirve para demascanamiento de datos en en tonos de prueba, y el data disclose es para tener un, en caso de que alguien nos pida saber qué datos se buscan de qué datos se conservan de él, pues con data diseclose podríamos hacer un reporte en PDF, en el que podríamos mostrar los datos que se encuentran en en producción de esa persona. Y vamos a dar ahora producto por producto de sus características. En primer lugar, tenemos el el data securi, que, básicamente, evita que los datos sensibles acaben en manos equivocadas y ayuda a cumplir con las normativas actuales. Entonces, enmascarar los datos sensibles, sobre todo en sistemas SAP no productivos, está listo, es decir, que tenemos una versión que no requiere desarrollo, solo seleccionar y listo, y no depende y todas las dependencias funcionales ya están pensadas y cubiertas. Se puede enmascarar un cliente SAP completo, o también se puede hacer por objetos, y es flexible. Aunque tengamos una reducción que ya esté hecha, también podemos añadir cualquier regla de codificación para añadir campos que, ya sean tablas z o otros procesos que esa empresa en particular y tenga que enmascarar, porque son datos sensibles, pero no están cubiertos por la por la política estándar. Decir. Luego, también tenemos client think y objectsing, que no están en el preiveriesheet, pero también participan en este proceso de cumplimiento de GDPR, ya que son soluciones de provisionamiento de datos. De esta manera, podemos reducir los sistemas de prueba hasta un setenta y cinco por ciento, es decir, que no deberíamos hacer una copia de producción a calidad entera, sino que podríamos coger solo un un un trozo, por así decirlo, de los datos transaccionales, y no tener que tener tantos datos históricos al final que no nos van a servir tanto para nuestras pruebas. Reducimos la carga de trabajado manual en un cincuenta por ciento. En el proceso en el que lo copiamos podemos ocultar los datos sensibles al exportarlos, y aumentamos, pues, la la la cobertura de enmascaramiento y aceleramos el proceso de precaución. Y luego vamos a hablar del data disclose, que es lo que os he dicho que busca de forma instantánea en todo el entorno SAP para localizar, recuperar y presentar el resto de datos de un sujeto con una descarga de PDF cifra. Ahora vamos a ver una demo tanto del discloss como del read para que entendáis mejor. Pero, básicamente, los beneficios son que es una búsqueda automatizada y rápida en todos los sistemas AVA. Puede ser en sistemas ERP, como en otros como CRM o CRM, y incluye incluye también sistemas no SAP que están definidos por, o sea, a través de APIs predefinidos. El data retain es lo que he dicho que es identificar de manera proactiva, es decir, no por una solicitud de un exempleado, sino de manera proactiva los sujetos de datos que requieren aninización, ya que se se basan en un conjunto de áreas flexibles que se pueden programar automáticamente o ejecutarse de manera manual según las necesidades de cumplimiento. Es decir, que podríamos ejecutar una vez al año este reporte nos identificaría los empleados o los clientes o los business spanish que cumpla con estos requerimientos. Por ejemplo, un empleado en España creo que son diez años en los que ya no estás obligado a conservar esa información, pues un reporte que identifique todos los empleados cada año que que ya no esté no no le quiera guardar sus datos. Y así nos aseguramos que nuestros sistemas están en cumplimiento y se anticipa sobre todo a las solicitudes de eliminación con una respuesta estandarizada. Esto es un pequeño vídeo que explica un poco cómo cómo funciona el data retain. Como podemos ver, tenemos una política de retención, en este caso son diez años, está localizando todos los datos importantes, se procesa y nos sale una lista de todos los empleados que irían a la cola de redacción. Vale, y por último, tenemos el dateRed Dag. El dateRedduct es, luego de haber hecho el el dateRed tain, o sea, haberle tenido esos empleados y esos clientes que ya no necesitamos, vamos a enviaros a la cola de dateRed, y el dateRed es el programa que lo que hace es que modifica o elimina de forma inteligente estos datos sensibles que se han encontrado, pero no borra el registro completo, ya que así se garantiza la integridad referencial de del sistema. Los beneficios es que la elaboración de informes con datos no sensibles no se ve afectada y cumple, obviamente, con la legislación que exija la eliminación de datos, y no necesitamos un archivado costoso ni soluciones de borrado personalizada. Aquí quiero mencionar un un pequeño desarrollo que hicimos para un cliente, para eMaya, que lo que hicimos es, en el data redact incluimos una funcionalidad que se llama bloqueo, que es en que llamamos bloqueo, que en este bloqueo que hicimos es que, aunque los empleados estuvieran redactados, se guardaban como en un cero, se guardaban en un, se guardaba la clave de estos empleados que se habían redactados redactado. Entonces, aunque se hubieran redactado y en el sistema se vieran enmascarados, teníamos la posibilidad de encontrar estos empleados a partir del DNI y cómo revertir estos cambios. Entonces, podíamos ver, aunque esta persona estuviera, se se llamara en el sistema, literalmente ponía redactado, podíamos introducir su DNI en un programa y nos decía cómo se llamaba esta persona antes en el en el en el sistema. Es decir, estaríamos cumpliendo con los requisitos de privacidad, ya que en el sistema no hay datos sensibles, pero si por alguna razón tuviéramos que volver a recuperar estos datos con este con este desarrollo, se podría, y esto es un requerimiento que en España se va se va a poder se va a tener que hacer en algunos casos, ya que se se pide conservar estos datos aunque ya hayan pasado diez años, por ejemplo, y esto es muy interesante. Y ahora vamos a pasar a las dos demos que hemos preparado para cada producto y os voy a ir explicando, es una valoración, pero yo os voy a ir explicando poco a poco. Entonces, para acceder a estos a estos productos hay que ejecutar la transacción barra use barra d p, y ahora vamos a ver primero el data disclosed, en el que podemos ver que introducimos, en este caso, el DNI del empleado, y vamos a seleccionar. Entonces, ahora nos va a aparecer el registro que cuenta para este DNI, y nos va a nos van a aparecer varios campos. Estos campos los podemos definir nosotros, es decir, podemos establecer qué campos se van a se van a encontrar con el data disclosE. Y una vez encontramos estos campos, vamos a poder procesar en lo que llamamos el pdf. El pdf es totalmente editable, ya que podemos añadir notas, podemos seleccionar los datos que van a salir en el pdf. Este pdf va con contraseña para cumplir, porque al final va a ser un PDF que va a llevar datos sensibles. Se se exporta, esa es muy fácil, y este PDF se lo enviaríamos a la persona que nos ha perdido estos datos, y ahora vamos a ver un ejemplo de cómo queda, que veremos que es un un documento bastante formal que perfectamente puede ser enviado, pues, formalmente, ¿no? Podemos incluir el logo, podemos incluir, podemos incluir el dos los, o sea, una descripción y los datos. Y ahora vamos a ver el el data litaniridad. Al data datain no lo he mostrado porque al final es ejecución un programa, pero vamos a ver cómo cómo es la cola del data datainity. Este empleado es el que ha encontrado programa de data datain y lo enviaríamos. Teníamos tres opciones, podamos probar la redacción, ejecutarla, o podemos borrar el empleado de la cola. Si ejecutamos ahora en un tomar modo test, se va a ejecutar esta redacción, entonces, podríamos ir al escrito de la monitorización, y aquí podríamos ver los valores antiguos y viejos. Esto, obviamente, porque lo estamos haciendo en test. Cuando lo hagamos en real, no podríamos ver los valores viejos y nuevos, porque no tendría sentido guardar un log que que guardara ambos valores, pero es interesando cuando estás probando la política, pues poder ver cómo quedarían estos datos. Como podemos ver, el mail se enmascara, los los nombres se enmascaran, los algunos DNI también se hacen más caras, y muchos datos directamente se borran. Esto se puede customizar con el cliente cuando se está haciendo el proyecto, y es superpersonalizable. Vale. ¿Qué es un período de reatención? Es, básicamente, el tiempo mínimo durante el cual los datos deben conservarse y el tiempo máximo antes de que los datos deban eliminarse. Y ahora vamos a hablar un poco de la cronología de un proyecto, es decir, de las diferentes fases que pasamos en un proyecto que incluiría toda la suite de privacidad. Las etapas preliminares siempre, siempre, siempre van a empezar con un análisis que llamamos data discovery, en el que identificamos con un con un programa que se importa en el sistema los datos que son sensibles y que serían susceptibles a ser enmascarados, Y luego se hace un taller colaborativo para decidir si estos datos se enmascararon o no, y el proceso de de los de estos datos, los parámetros de búsqueda y la generación de los PDF, es decir, todos los todos los inputs que necesitamos para poder ejecutar estos estos productos. Luego iría la implementación del data disclose, que sería la personalización del formato, pues añadiríamos un logo, una descripción, los parámetros de búsqueda, como hemos dicho, podemos buscarlo por DNI, pero también podemos buscarlo por nombre, por el número de personal, por calle, por lo que sea, y luego los parámetros de salida, es decir, los parámetros que van a salir en el reporte final. Entonces, sería la implementación de data data, que es la configuración de una política personalizada en el entorno no productivo, y la la prueba de integración con data datain y data discrobs. Y luego, esto se desplegaría en producción. Y, por último, la implementación del data litane, que iría un poco ligada al data redact, que sería aplicar los criterios de retención y asegurar que las personas interesadas se sometan a esta ofuscación de datos. Y, por último, perdón, la implementación del data sicles, que sería la configuración y la prueba de una política totalmente personalizada. La ruta de implementación, como he dicho, sería el taller de identificación y reuniones con los equipos. Y el taller de privacidad, más en detalle, porque eso es una parte muy importante en la que nosotros, como empresa, ponemos mucho interés y, al final, es como lo que se va. Queremos que esta parte sea muy importante y que tome mucha importancia también por el cliente, ya que, al final, paga a a definir el alcance de todo el proyecto y luego todo lo que se haga. Y puede ser un poco pesado, por así decirlo, porque al final, pues, es un un proceso muy interactivo en el que se hacen muchas preguntas y al final, pues, es un proceso costoso, pero vale la pena invertir tiempo en él para que luego el resultado al final sea mucho mejor. Entonces, el taller es un taller, como como he dicho, siempre insistimos en esto colaborativo, seguido de un análisis que hacemos por nuestra parte. No tienen que hacer los clientes en en profundidad del sistema. Un pequeño servicio de consultoría que requiere por nuestra parte también una red una semana de trabajo en el que se hace un día de talleres, tres días de análisis de un sistema, probablemente tres días más para el análisis de otro sistema. O, por ejemplo, si se usan por varios productos, se requerirían diferentes análisis. Esto es muy personal según el cliente, según el tamaño del sistema, según los productos que se hayan adquirido, pero siempre se hace este taller. Entonces, nosotros lo que hacemos es que aportamos experiencia en nuestras soluciones SAP con un historial de implementación de proyectos de privacidad en últimas empresas, y ayudamos con las necesidades de funcionales, de cumplimiento, de pruebas, aportamos ejemplos reales. Entonces, al final se presenta un informe detallado que incluye los requisitos de privacidad, tanto en entornos no productivos como productivos, los privacidad, tanto en entornos no productivos como productivos, los procesos de retención, la definición de objetos, las integraciones que se hayan definido, y un análisis detallado de las tablas y campos que muestran información personal. Y por último, como mencioné el término al principio, se va a mencionar el un tax story, es decir, un un cliente nuestro que que implementó estas soluciones. Este se trata de Nesle que consiguió mejorar una confidencialidad de sus datos, ya que implementó soluciones como data discots y data retain, con el objetivo de aplicar sus políticas de protegida en un sistema de HR en sistemas productivos como en, o sea, tanto en sistemas productivos como en sistemas no productivos y de preproducción. Entonces, gracias a una estrecha colaboración, se se desarrollaron reglas específicas para cada país, que eso también es importante mencionarlo, lo que permitió garantizar que los sistemas SAP de Nestlé cumplieran con los GDPR, no de cada país. Es decir, porque cada país sabemos que tiene diferentes reglas. Y en una empresa que abarca tantos países, pues, hay muchas cosas a tener en cuenta. Como estoy diciendo, al final Nesleft es una empresa amplia y compleja que cuenta con trescientos mil empleados, numerosos colaboradores externos, ochenta y dos países. Al final, se se usó nuestra herramienta para copiar y clonar los datos, y se y se crearon estándares internos de privacidad en los que esta data Primercy Suite se usó para cubrir las necesidades, ya que es, sobre todo, una una herramienta altamente flexible. Y ya pasaríamos a la parte de preguntas, aunque creo que no queda mucho tiempo. Así que, Stefany, corrígeme, pero si no, sí se contestarán por mí. Muchas gracias, Andrea, por este webinar tan claro y útil, y también gracias a ustedes por acompañarnos. Efectivamente, hemos recibido alguna pregunta, pero ya no tenemos casi tiempo, así que les llegarán todas las respuestas por correo. Y bueno, de nuevo, no se olviden de seguirnos en nuestra página de LinkedIn, Epi's Labs en español, para estar al tanto de nuestras novedades y eventos en dos mil veinticinco y dos mil veintiséis. Les agradecemos muchísimo su atención y desde Apreus Labs le deseamos a todos un buen día.