RGPD en el desarrollo de software: lo que tu proveedor debe garantizarte

Casi cualquier software de empresa trata datos personales: clientes que reservan una cita, empleados que fichan, pacientes con su historial o compradores con su dirección de entrega. Cuando encargas una aplicación a medida, tu empresa sigue siendo la responsable de esos datos ante la ley. Conocer qué exige el Reglamento General de Protección de Datos (RGPD) en el desarrollo te permite pedir a tu proveedor lo que necesitas y evitar problemas después del lanzamiento.

Las obligaciones que más pesan en un proyecto de software aparecen aquí en el orden en que surgen durante el encargo. Primero vienen el reparto de papeles y el contrato. Después llegan el diseño, la seguridad y el alojamiento. La parte final trata las brechas y las preguntas que conviene hacer al proveedor antes de firmar. Cada apartado termina en decisiones que se pueden comprobar en la aplicación.

Quién es quién en un proyecto de software

El RGPD reparte las obligaciones según el papel de cada empresa en el tratamiento de los datos. Conviene tenerlo claro desde la primera reunión, porque de ese reparto dependen los contratos que hay que firmar y quién responde ante la AEPD si algo falla. En un proyecto de software aparecen tres figuras:

• Responsable del tratamiento. Es tu empresa, que decide para qué y cómo se usan los datos.
• Encargado del tratamiento. Es el proveedor que trata los datos por cuenta tuya, por ejemplo al desarrollar, alojar o mantener la aplicación.
• Subencargado. Es un tercero al que el encargado recurre, como el centro de datos donde se aloja la aplicación o el servicio que envía los correos.

En España, el RGPD se complementa con la Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD). La autoridad de control es la Agencia Española de Protección de Datos (AEPD), que inspecciona, resuelve reclamaciones y sanciona.

Una empresa de desarrollo que solo escribe código y nunca ve datos reales no llega a ser encargada. En cuanto migra una base de datos antigua, entra en producción para resolver una incidencia o aloja la aplicación, sí lo es. En la práctica, casi todos los proyectos a medida acaban en esa situación.

Las bases que el diseño tiene que respetar

Antes de hablar de técnica conviene recordar los principios del artículo 5, porque cada uno se traduce en una decisión de diseño. Los datos se tratan de forma lícita y transparente, con una finalidad concreta, en la cantidad mínima necesaria, exactos, durante el tiempo justo y con seguridad. El reglamento llama responsabilidad proactiva a la obligación del responsable de poder demostrar que cumple todo ello.

Cada tratamiento necesita además una base jurídica del artículo 6. En el software de empresa la más habitual es la ejecución de un contrato, como gestionar el pedido de un cliente. Le siguen el cumplimiento de una obligación legal, como conservar facturas, y el consentimiento, que es la base de un boletín comercial. La base decide qué puede hacer la aplicación con cada dato. Un dato recogido para gestionar un pedido no puede reutilizarse para publicidad sin otra base que lo permita.

Privacidad desde el diseño y por defecto

El artículo 25 del RGPD obliga a pensar en la protección de datos desde que se diseña la aplicación y durante todo su desarrollo. La AEPD publica una guía de privacidad desde el diseño que sirve de referencia. En la práctica se traduce en decisiones concretas que un equipo de desarrollo puede enseñarte:

• Minimización. Cada campo del formulario tiene una razón. Si la aplicación no necesita la fecha de nacimiento, el formulario la omite.
• Configuración por defecto protectora. Las opciones que afectan a la privacidad empiezan en el valor más restrictivo, como un perfil que no es público hasta que la persona lo decide.
• Plazos de conservación. Los datos se borran o se anonimizan cuando dejan de ser necesarios, mediante tareas automáticas y no con limpiezas manuales que nadie recuerda.
• Derechos de las personas. El sistema facilita el acceso, la rectificación, la supresión y la portabilidad sin depender de que alguien busque a mano en la base de datos.
• Separación de entornos. Las pruebas se hacen con datos ficticios y el acceso a producción queda limitado y registrado.

Los derechos, resueltos por la propia aplicación

Las personas pueden pedir acceso a sus datos, rectificarlos, suprimirlos, limitar su tratamiento, oponerse a él y llevárselos a otro servicio. El artículo 12 da un mes para responder, ampliable dos meses más en casos complejos. Una aplicación bien diseñada permite descargar los datos en un formato estructurado y borrar la cuenta desde el área privada. Esas dos funciones resuelven la mayoría de solicitudes y dejan rastro de cuándo se atendieron.

El borrado tiene matices. Hay datos que la ley obliga a conservar, como las facturas, que el Código de Comercio manda guardar seis años. En esos casos la aplicación anonimiza lo que puede, bloquea el resto y lo conserva solo para atender esa obligación.

El contrato de encargado del tratamiento

El artículo 28 exige un contrato por escrito con cualquier proveedor que trate datos por tu cuenta. Pide este contrato antes de dar acceso a cualquier dato real. Tiene que recoger como mínimo estos puntos:

La lista de subencargados merece una lectura atenta. Una aplicación moderna puede depender de un proveedor de nube, uno de correo transaccional, uno de monitorización de errores y, cada vez más, uno de inteligencia artificial. Cada uno trata datos personales y cada uno tiene que aparecer en el contrato.

Seguridad: lo mínimo que debes exigir

El artículo 32 pide medidas técnicas y organizativas adecuadas al riesgo. El reglamento no da una lista cerrada, pero cita la seudonimización, el cifrado, la capacidad de restaurar los datos tras un incidente y la comprobación periódica de las medidas. Para una aplicación de empresa, esto incluye como mínimo:

Un proveedor que trabaja con buenas prácticas puede explicarte cómo cubre cada punto y enseñarte la evidencia. Una respuesta genérica del tipo «la aplicación es segura» no sirve para demostrar nada ante la AEPD.

Dónde están los datos

Si la aplicación se aloja en la nube o usa servicios externos de correo, mapas o inteligencia artificial, comprueba dónde se guardan y procesan los datos. Alojarlos en la Unión Europea simplifica el cumplimiento. Las transferencias fuera del Espacio Económico Europeo exigen garantías adicionales del capítulo V del RGPD.

Para Estados Unidos existe desde julio de 2023 una decisión de adecuación de la Comisión Europea que cubre a las empresas adheridas al Marco de Privacidad de Datos UE-EE. UU. Para otros países sin decisión de adecuación se usan cláusulas contractuales tipo, acompañadas de una evaluación del riesgo de la transferencia. Elegir la región europea de un proveedor de nube suele resolver el problema de raíz.

Registro de actividades y evaluación de impacto

El artículo 30 obliga a llevar un registro de las actividades de tratamiento con su finalidad, los datos, los destinatarios, los plazos de conservación y las medidas de seguridad. La exención para empresas de menos de 250 empleados no se aplica cuando el tratamiento no es ocasional, que es el caso de casi cualquier aplicación de negocio. Cada aplicación nueva añade entradas a ese registro.

El artículo 35 exige una evaluación de impacto cuando el tratamiento puede suponer un alto riesgo, por ejemplo con datos de salud a gran escala, con perfiles automatizados que deciden sobre las personas o con vigilancia sistemática. La AEPD publica listas de tratamientos que la requieren. Si tu aplicación entra en estos supuestos, la evaluación se hace antes de empezar a tratar los datos y su resultado puede obligar a cambiar el diseño.

Si algo sale mal: brechas de seguridad

Una brecha es cualquier incidente que destruye, pierde, altera o expone datos personales, desde un ataque informático hasta un portátil olvidado o un correo enviado a quien no debía. El artículo 33 obliga a notificarla a la AEPD en un plazo de 72 horas desde que se conoce, salvo que sea improbable que suponga un riesgo para las personas. Si el riesgo es alto, el artículo 34 obliga a comunicarla también a los afectados.

Plazo para notificar una brecha a la AEPD

72 h

Plazo para responder a un derecho

1 mes

Sanción máxima

20 M€ o 4 %

Tu proveedor debe avisarte sin demora de cualquier incidente y ayudarte con la notificación. Comprueba que el contrato lo recoge y que la aplicación guarda los registros necesarios para saber qué datos se vieron afectados y desde cuándo. Sin esos registros, la notificación se queda en conjeturas.

Las sanciones del artículo 83 pueden alcanzar los 20 millones de euros o el 4 % de la facturación anual mundial en los casos más graves. Otros incumplimientos tienen un máximo de 10 millones o el 2 %. Para una pyme el mayor coste suele ser la pérdida de confianza de sus clientes, que llega antes que cualquier multa.

Preguntas para tu proveedor

Antes de firmar conviene oír de la empresa de desarrollo cómo resuelve cada punto anterior, con respuestas concretas y comprobables. Una empresa con experiencia contesta sin rodeos y puede enseñar el contrato tipo, la lista de subencargados y la política de copias que usa en otros proyectos. Las siete preguntas siguientes cubren lo esencial del contrato, la seguridad y la salida del proveedor:

1. ¿Firmamos un contrato de encargado del tratamiento antes de que veáis datos reales?
2. ¿Dónde se alojarán los datos y qué subencargados intervienen?
3. ¿Qué medidas de seguridad aplicáis y cómo las comprobáis?
4. ¿Cómo facilita la aplicación los derechos de los usuarios?
5. ¿Cómo se borran o anonimizan los datos cuando vence su plazo?
6. ¿Qué haréis si detectáis una brecha de seguridad y cómo nos avisaréis?
7. ¿Qué pasa con los datos y con las copias si dejamos de trabajar juntos?

Encontrarás más preguntas útiles para elegir proveedor en cómo elegir una empresa de desarrollo de software.

En resumen

El RGPD se cumple mejor cuando se diseña desde el principio: datos mínimos, plazos de borrado automáticos, derechos resueltos desde la propia aplicación, seguridad comprobada, contrato de encargado firmado y datos en la Unión Europea siempre que sea posible. Pide estas garantías por escrito a tu proveedor. En Viuzi aplicamos estos principios en cada proyecto, como puedes ver en nuestro servicio de consultoría tecnológica.

Preguntas frecuentes

¿Quién responde ante la AEPD si la aplicación incumple el RGPD?

Responde principalmente tu empresa como responsable del tratamiento, porque decide para qué y cómo se usan los datos. El proveedor responde como encargado cuando incumple las obligaciones que el RGPD le impone directamente o actúa fuera de tus instrucciones. Por eso el contrato de encargado y las instrucciones escritas protegen a las dos partes.

¿Necesito un delegado de protección de datos para mi aplicación?

Depende de la actividad. El artículo 37 del RGPD lo exige cuando la actividad principal consiste en observar a personas de forma habitual y sistemática a gran escala o en tratar a gran escala categorías especiales de datos, como los de salud. La LOPDGDD añade en su artículo 34 una lista de entidades obligadas, entre ellas los centros sanitarios, los centros docentes y las empresas de servicios de la sociedad de la información que elaboran perfiles a gran escala.

¿Puedo usar datos reales de clientes para probar la aplicación?

Solo si es necesario y con las mismas garantías que en producción. Lo recomendable es probar con datos ficticios o anonimizados. Si hay que usar datos reales, por ejemplo para migrar un sistema antiguo, el acceso se limita a las personas imprescindibles y queda cubierto por el contrato de encargado.

¿Cuánto tiempo puedo guardar los datos de mis clientes?

El tiempo necesario para la finalidad para la que los recogiste, más el que exija una ley. Las facturas y los libros contables se conservan seis años por el Código de Comercio, y la información con efectos fiscales al menos durante el plazo de prescripción de cuatro años. Pasados esos plazos, la aplicación debería borrar o anonimizar los datos de forma automática.

¿Puedo usar servicios en la nube de empresas estadounidenses?

Sí, con garantías. Desde julio de 2023 la Comisión Europea considera adecuado el nivel de protección de las empresas estadounidenses adheridas al Marco de Privacidad de Datos UE-EE. UU. Para el resto hacen falta cláusulas contractuales tipo y una evaluación del riesgo. Elegir la región europea del proveedor cuando existe reduce mucho el trabajo.

¿Cuánto tiempo tengo para responder a una persona que pide sus datos?

Un mes desde que recibes la solicitud, ampliable dos meses más si la petición es compleja o hay muchas, avisando al interesado dentro del primer mes. Una aplicación que permite descargar los datos o borrar la cuenta desde el área privada resuelve la mayoría de solicitudes sin intervención manual.

Fuentes

1. Reglamento (UE) 2016/679, Reglamento General de Protección de Datos (EUR-Lex)
2. Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales (BOE)
3. Guía de privacidad desde el diseño (AEPD)
4. Guía para la gestión y notificación de brechas de datos personales (AEPD)
5. OWASP Top 10, riesgos de seguridad de las aplicaciones web

Quién escribe

Equipo de Viuzi

El equipo de Viuzi diseña, construye y mantiene software a medida para pymes y empresas desde Málaga. Escribimos estas guías con lo que vemos cada semana en proyectos reales y revisamos los datos normativos contra su fuente oficial.

Conoce al equipo →

Sigue leyendo

• Inteligencia artificial

  Inteligencia artificial para pymes: siete usos que ya funcionan y cómo empezar

  13 min de lectura

• Costes y contratación

  Cómo elegir una empresa de desarrollo de software: 12 preguntas antes de firmar

  11 min de lectura

• Normativa

  Factura electrónica obligatoria entre empresas: calendario y cómo prepararse

  14 min de lectura