MyZapp

Plazos de conservación y borrado

Available in en es fr

Updated on 11/04/2026

Los datos personales solo se conservan el tiempo que exige su finalidad (artículo 5.1.e del RGPD). MyZapp borra cada categoría de datos al final del plazo que fijas en el registro de tratamientos, categoría por categoría, y guarda constancia de cada ejecución.

La pantalla está en Protección de datos › Plazos de conservación. Todo el módulo puede leerla; solo los delegados de protección de datos (y los administradores) la modifican.

Qué muestra la tabla

Una línea por categoría de datos que los módulos saben borrar: mensajes enviados, solicitudes reguladas, registros (auditoría, inicios de sesión, accesos sensibles…).

Columna Contenido
Categoría El dato afectado y su módulo. Una etiqueta Retención legal señala un borrado suspendido.
Punto de partida Desde dónde se cuenta: fecha del registro, cierre del expediente…
Plazo El plazo del registro y la actividad que lo lleva, o el ajuste que lo rige en otro lugar.
Política Simulación o Aplicación, y la acción final: Anonimizar o Eliminar.
Última ejecución Fecha, resultado y, en simulación, el número de elementos que se tratarían.
Tratados (12 meses) Volumen realmente borrado en el año.

Fijar el plazo: en el registro

El plazo se fija en la ficha de la actividad de tratamiento, campo Plazo de conservación (meses). Si varias actividades vigentes llevan la misma fuente, gana la más larga: un dato nunca se borra antes del final de su finalidad más larga.

Sin plazo en el registro, la categoría muestra Ningún plazo en el registro: no se calcula ni se borra nada.

Primero simulación, luego aplicación

Una categoría está en simulación mientras no la pases a aplicación. Cada noche, la tarea cuenta lo que se trataría, sin tocar nada; el registro lo indica. Simular ahora hace lo mismo a petición, sin aplicar nunca.

Cuando la cifra te parezca bien:

  1. En la columna Política, elige Aplicación y la acción final.
  2. Haz clic en Guardar.

El borrado empieza en la ejecución de la noche siguiente, por lotes. Un error deja los datos intactos: la categoría se retoma la noche siguiente.

Un litigio, una inspección de la autoridad o una investigación obligan a conservar los datos tal cual.

  1. En Retenciones legales, elige la categoría, o Todas las categorías.
  2. Escribe el motivo, sin ningún dato personal, y si es posible una fecha Revisar el.
  3. Haz clic en Retener el borrado.

Mientras la retención está vigente, la categoría deja de borrarse, solicitudes reguladas incluidas. Pasada la fecha de revisión, la retención muestra Por revisar. Levantar la retención, con una nota, restablece el borrado.

Cuentas inactivas y tickets

  • Cuentas inactivas: una cuenta que no ha iniciado sesión durante el plazo fijado en el registro (actividad de las cuentas de usuario) se desactiva: ya no puede iniciar sesión, sus sesiones abiertas se cierran y un administrador puede volver a activarla. Si eliges la acción Anonimizar, la cuenta se anonimiza como al eliminarla. Los administradores, la cuenta Sistema y las cuentas sincronizadas desde un directorio nunca se tocan.
    • Aviso: en aplicación, la persona recibe primero un correo que le anuncia la fecha de desactivación. La cuenta solo se desactiva (o anonimiza) 30 días después, y solo si no ha iniciado sesión entretanto: iniciar sesión lo anula todo. El plazo se ajusta en la configuración (Users:Inactivity:NoticeDays, 0 = sin aviso). En simulación no se envía ningún correo.
  • Accesos de invitados a los tickets: cuando el enlace de acceso ha vencido o se ha revocado, la dirección del invitado se elimina al cumplirse el plazo del registro. El ticket y sus mensajes se conservan.
  • Marcas de lectura de los tickets (quién leyó qué ticket y cuándo): se eliminan al cumplirse el plazo del registro.

Archivo intermedio (acceso restringido)

Entre el fin del uso corriente y el borrado, algunos datos pasan a un archivo intermedio: siguen en la base de datos, pero desaparecen de las pantallas, búsquedas y exportaciones corrientes. Solo el delegado (grupo PRIVACY_DPO) y los miembros del grupo PRIVACY_ARCHIVES (litigios, controles) pueden verlos, y cada consulta queda registrada en el registro de accesos sensibles.

  • El plazo se fija en el registro, en la actividad: «Uso corriente (meses), luego archivo». Debe ser más corto que el plazo de conservación. Vacío: sin archivo intermedio.
  • El archivo sigue la misma regla que el borrado: primero simulación, luego aplicación, y un bloqueo legal lo suspende. El registro de borrados muestra una línea «Archivar (acceso restringido)».
  • Hoy, las solicitudes reguladas cerradas (sin recurso en curso) se archivan así. El solicitante conserva el acceso a sus propias solicitudes, y la ejecución de una solicitud de derechos las sigue encontrando.
  • Los proyectos terminados o cancelados también se archivan: salen de la lista y de los paneles de todos, miembros incluidos; el delegado y el grupo de archivos los abren en solo lectura.
  • Los tickets cerrados se archivan igual: salen de la lista, las cuadrículas, las búsquedas, las exportaciones y las estadísticas de los agentes. El solicitante conserva el acceso a sus propios tickets; el delegado y el grupo de archivos los leen, y cada apertura queda registrada. Reabrir un ticket lo devuelve al uso corriente.
  • Las inscripciones de la Academia sin actividad también se archivan: salen de la pantalla del formador y ya no generan recordatorios. El alumno las encuentra y las retoma; cualquier actividad las devuelve al uso corriente. Las certificaciones nunca se archivan: son pruebas.
  • Los contactos y prospectos del CRM sin ninguna actividad (correo, llamada, reunión, presupuesto, oportunidad) durante el uso corriente también se archivan: salen de las listas, búsquedas, exportaciones y de la API, incluso para su propietario; el delegado y el grupo de archivos los abren en solo lectura. Un contacto de una organización con un contrato activo o una factura pendiente nunca se archiva. Cualquier actividad nueva devuelve la ficha al uso corriente.

Categorías fijadas en otro lugar

  • Registros (auditoría, inicios de sesión, accesos denegados, llamadas a la API, accesos sensibles): su plazo se fija en el servidor, por categoría de registro. La tabla muestra ese ajuste; el borrado sigue siendo el de los registros, que guarda la prueba de cada supresión.
  • Conversaciones del asistente (un plazo por público) y transcripciones de llamadas del CRM: su plazo se fija en los ajustes del asistente y del CRM. La tabla lo muestra.
  • Solicitudes reguladas: su plazo viene del modelo de país, ampliado por la entidad en los ajustes de la ventanilla. La tabla indica «Plazos fijados por el módulo»; la retención legal se les aplica.

Registro de borrados

Cada ejecución escribe una línea por categoría: fecha, modo, fecha límite, elementos vencidos, elementos tratados, resultado (Simulado, Aplicado, Retenido, Sin plazo, Interrumpido (tiempo), Error). El registro no contiene ningún dato personal y se conserva dos años.

Applies from version 1.0 Verified for version 1.0

Was this article helpful?

Still need help? Create a request