Tenéis razón, el tema no es solo técnico. A continuación os doy una hoja de ruta general; os recuerdo que para vuestro caso concreto debéis consultar la normativa y a vuestro asesor.
El primer paso es el inventario. Qué datos personales tratáis, con qué finalidad, basándoos en qué base legal; dónde se almacenan, quién tiene acceso, cuánto tiempo se conservan, a quién se transfieren. Sin este cuadro, ningún paso que deis será sólido.
El segundo paso es la finalidad y la minimización. El error más común que veo en proyectos de software es recopilar más campos de los necesarios pensando "por si acaso nos hace falta luego". Los datos que no se recogen son datos que no hay que proteger. Cada campo del formulario debe tener una justificación.
El tercer paso es la información y, si procede, el consentimiento explícito. Cuándo y cómo se recogen estos elementos forma parte de la interfaz; no es una casilla de verificación que se añade después. Por eso hay que hablarlo con el programador desde el principio.
El cuarto paso es la conservación y la destrucción. Debe estar por escrito cuánto tiempo se conservan los datos y qué pasa al final del plazo, y el software debe tener la funcionalidad correspondiente. En un sistema sin función de borrado, la política de destrucción se queda solo en papel.
El quinto paso son las solicitudes de los interesados. Cuando una persona pregunta por sus datos o pide que se borren, debe estar definido quién, en qué plazo y por qué canal lo gestiona. Escribid en el pliego de condiciones si el software soporta esto o no.
Por último, al contrato que firméis con vuestro programador deben añadirse cláusulas de tratamiento de datos; si vuestro proveedor tiene acceso a los datos, el marco de esta relación debe estar por escrito.