2026-06-27

Guardar los datos en la unidad del cliente: la filosofía de diseño de la retención mínima de datos

Cómo reducir el riesgo de fuga de información de un SaaS de negocio. Explicamos el enfoque de diseño de mantener los datos del lado del cliente y minimizar la retención en el servidor.

Cuanto más se acumula, mayor es el riesgo

Cuantos más datos de clientes se acumulan en los servidores del proveedor, mayor es el daño ante un ataque. Al contrario, si se reducen los datos que quedan en el servidor, se puede reducir de forma estructural el alcance del impacto en caso de incidente. Cuanto menos haya que proteger, más sencilla puede ser la protección y menos probable que se escape algún punto en las revisiones. El punto de partida es preguntarse, al inicio del diseño, «¿de verdad hace falta que esto se quede en el servidor?».

Los datos, en la unidad del cliente

Si el destino final de los informes diarios es una hoja de cálculo dentro del propio Google Drive del cliente, el control de los datos vuelve al lado del cliente. El proveedor solo hace de intermediario y no los conserva a largo plazo. El cliente puede decidir por sí mismo quién los ve mediante los permisos de acceso de su empresa, y aunque termine el contrato, los datos permanecen en sus manos. Un diseño que no toma los datos como rehén también aporta tranquilidad en la implantación.

Acotar en el tiempo la retención en el servidor

El servidor solo guarda los datos temporales entre el envío y la aprobación, y los borra al aprobar; si no se aprueban, se borran automáticamente como máximo a las 24 horas. Poder afirmar con claridad que «solo permanecen 24 horas como máximo» facilita superar la revisión del lado que implanta. Lo importante es que el borrado funcione automáticamente sin depender de una acción humana y que el límite de retención pueda explicarse con palabras. Con un ambiguo «se borra lo antes posible», quien revisa no puede decidir.

Borrar no basta por sí solo

La retención mínima es potente, pero no basta por sí sola para estar seguros. Solo cuando se combinan las bases, como el cifrado de las comunicaciones, la separación de permisos de escritura y el registro de las operaciones, se llega a un estado que se puede usar con tranquilidad. Por ejemplo, si se piensan como un conjunto los tres puntos —que un tercero no pueda leer los datos mientras están retenidos, que los destinos de escritura se limiten a lo necesario y que después se pueda rastrear qué ocurrió—, se escapan menos cosas.

Ejemplos de preguntas para comprobar antes de implantar

Quien evalúa la implantación puede, como pauta, hacer al proveedor las siguientes preguntas: «¿Dónde están los datos en sí?», «¿Hasta cuándo como máximo permanecen en el servidor?», «¿El borrado es automático o manual?», «Si quiero retirar los permisos, ¿cuál es el procedimiento?». Cuanto más concretas sean las respuestas y más se puedan explicar como un mecanismo, más fácil es juzgar que el diseño está bien ordenado. En cambio, si la respuesta depende del cuidado del responsable de operaciones, ese es un punto que tiende a ser débil. Por último, conviene comprobar también si la explicación del diseño consta por escrito, lo que resulta útil en las aprobaciones internas y en las revisiones.