ERP y protección de datos: qué te exige el RGPD a la hora de elegirlo

El ERP suele ser la mayor concentración de datos personales de una empresa: clientes con su identificación fiscal, empleados con su nómina, contactos de proveedores, y a veces historial de compras al detalle. Aun así, la protección de datos rara vez aparece en la lista de criterios cuando se elige, y aparece tarde —normalmente cuando el departamento legal lee el contrato la semana antes de firmar.

Esta guía no sustituye al asesoramiento jurídico. Lo que hace es traducir a preguntas concretas de compra lo que el RGPD implica para un ERP, que es la parte que acaba decidiendo el proyecto.

El reparto de papeles: tú eres el responsable

La primera idea, y la que más consecuencias tiene: la empresa que usa el ERP es la responsable del tratamiento. El fabricante o el partner que lo aloja y lo mantiene es, normalmente, encargado del tratamiento.

Eso significa que la responsabilidad frente a un cliente o un empleado cuyos datos se hayan gestionado mal es de la empresa, no del proveedor del software. El proveedor responde ante ti según lo que hayáis firmado; tú respondes ante el afectado y ante la autoridad de control.

De ahí se sigue lo más importante en la práctica: hace falta un contrato de encargado de tratamiento con quien acceda a esos datos. Y quien accede no es solo el fabricante del ERP: también el partner implantador que entra a dar soporte, y cualquier proveedor de la nube donde el sistema esté alojado. Es habitual tener firmado el del fabricante y no el del partner que realmente se conecta a diario.

Qué preguntar al proveedor antes de decidir

Estas preguntas se hacen en la fase de evaluación, no después. Las respuestas deberían constar por escrito.

¿Dónde se almacenan los datos? Con ERP en la nube, la ubicación de los centros de datos importa: si salen del Espacio Económico Europeo hacen falta garantías adicionales para esa transferencia. Que el proveedor sea europeo no garantiza que el alojamiento lo sea.

¿Quién puede acceder y con qué perfil? Un ERP mal configurado deja que cualquier usuario de administración vea las nóminas. Hay que poder limitar el acceso por rol de forma granular, y no solo por módulo.

¿Hay registro de accesos? Poder saber quién consultó qué y cuándo es lo que permite detectar e investigar un acceso indebido. Sin traza, no hay nada que investigar.

¿Cómo se borra un dato? Es la pregunta que más incomoda. Cuando un cliente ejerce su derecho de supresión, ¿el ERP permite eliminar sus datos personales manteniendo los asientos contables que hay obligación legal de conservar? Un sistema que solo ofrece «borrar todo» o «no borrar nada» convierte cada solicitud en un problema manual.

¿Qué pasa con los entornos de prueba? Copiar la base de datos de producción a un entorno de pruebas es lo normal, y multiplica el número de copias de datos personales fuera de control. Conviene preguntar si el producto ofrece anonimización o enmascarado para esos entornos.

¿Cómo se exportan los datos si nos vamos? La portabilidad es un derecho de los afectados, pero además es tu seguro: un formato de exportación completo y documentado es lo que permite cambiar de sistema sin rehenes.

¿Cómo se notifica una brecha? Los plazos de notificación son cortos. El contrato debe obligar al proveedor a avisarte sin dilación, con un canal y un responsable definidos.

Lo que hay que configurar del lado de la empresa

Buena parte del cumplimiento no depende del producto sino de cómo se implanta.

Perfiles por función, no por comodidad. El atajo clásico —dar permisos amplios «para que no molesten con incidencias»— es el origen de la mayoría de los accesos indebidos. Revisar los perfiles debe ser una tarea periódica, especialmente cuando alguien cambia de puesto.

Bajas de usuario el mismo día. Las cuentas de personas que ya no están son el agujero más común y el más fácil de cerrar. Conviene que la baja del ERP forme parte del procedimiento de salida.

Política de conservación escrita. Los datos personales no se guardan indefinidamente porque el disco sea barato. Hay que decidir cuánto se conserva cada cosa, distinguiendo lo que tiene plazo legal —la documentación contable y fiscal— de lo que no lo tiene.

Copias de seguridad incluidas en el razonamiento. Una copia es también un tratamiento: dónde se guarda, cuánto vive y quién puede restaurarla forma parte del análisis.

Registro de actividades de tratamiento actualizado. Cuando se implanta un ERP nuevo, o se le añade un módulo que trata datos que antes no se trataban, ese registro hay que actualizarlo. Suele olvidarse.

Qué mirar en el contrato

Estas cláusulas son las que después resultan caras si no están. Merece la pena revisarlas junto con el resto de puntos del contrato de ERP.

• Contrato de encargado de tratamiento firmado, con objeto, duración, tipos de datos y categorías de afectados descritos de verdad, no como anexo genérico.
• Lista de subencargados —alojamiento, soporte de terceros, servicios integrados— y obligación de comunicar cualquier cambio con margen para oponerse.
• Ubicación del tratamiento y régimen aplicable a transferencias fuera del EEE.
• Medidas de seguridad concretas: cifrado, control de accesos, registro de auditoría.
• Obligación de notificación de brechas con plazo y canal.
• Devolución o destrucción de los datos al terminar, con formato y plazo. Y qué ocurre con las copias de seguridad, que suelen sobrevivir al contrato.
• Derecho de auditoría o, al menos, entrega de certificaciones e informes independientes.

Nube y on-premise: no es más seguro lo que está en casa

Existe la intuición de que tener el ERP en un servidor propio protege mejor los datos. No es así de forma automática: cambia quién asume el trabajo.

Con ERP en la nube se depende de las medidas del proveedor, pero esas medidas suelen estar documentadas, auditadas y actualizadas. Con ERP en las instalaciones propias el control es total y también lo es la responsabilidad: las actualizaciones de seguridad, el cifrado de las copias y el control de acceso físico pasan a ser tarea de la empresa. Un servidor sin parchear bajo una mesa no es una arquitectura más protegida, es una con menos testigos.

El momento de tratarlo

El error más caro es dejar la protección de datos para el final. Dos decisiones que se toman al principio del proyecto —dónde se aloja el sistema y cómo se diseñan los perfiles de acceso— son precisamente las que después cuestan mucho dinero cambiar.

Lo razonable es incluir estas preguntas en el proceso de evaluación, junto a las funcionales, y resolverlas antes de firmar. Cuando se implanta con los perfiles bien pensados desde el primer día, el cumplimiento sale casi gratis; cuando se reconstruyen después, es un proyecto entero.

Si estás en fase de selección, el resto de criterios está en las guías de cómo elegir un partner implantador y de implantación paso a paso. En el directorio de software de gestión empresarial de Dataprix hay fichas y análisis de los productos con los que comparar candidatos.