Tema
Pregunta 25 — Retención mínima y eliminación segura de datos
| Campo | Valor |
|---|---|
| Destinatario | José David Álvarez — QSA ControlCase |
| Documento | Q25-RESP-2026-08 |
| Fecha | 2026-08-16 |
| Documento base | DOC-DATA-RET-01 — Procedimiento de Retención y Eliminación Segura v1.0 |
| Controles PCI | Req 3.2.1, 3.3.1, 9.4.x, 10.5.1 |
| Elaborado | Gabriel Ureña Chacón — CTO Fintrix Pay |
1. Alcance de esta respuesta
Se aportan los períodos de retención aplicables y la evidencia de ejecución real de cada mecanismo de eliminación, verificados sobre el entorno en producción el 2026-08-16.
Los elementos de naturaleza organizativa o física que no podemos demostrar técnicamente se relacionan en §6 y no se declaran como ejecutados.
2. Períodos de retención — inequívocos
| Tipo de dato | Período | Evento que inicia el conteo | Fundamento |
|---|---|---|---|
| Datos de autenticación sensibles (código de verificación, PIN, banda) | 15 minutos | Momento de la tokenización | Req 3.3.1 — no almacenables tras la autorización |
| Número de tarjeta | 30 días | Marca de baja lógica del registro | Necesidad operativa de conciliación y contracargo |
| Copias de seguridad de base de datos | 3 años | Fecha de la copia | Bloqueo de objeto en modo cumplimiento |
| Registros de auditoría | 3 años | Fecha del evento | Req 10.5.1 exige 12 meses; se conserva el triple |
| Material criptográfico | 7 años | Fecha del respaldo | Recuperación ante desastre |
| Estado de infraestructura | 90 días | Fecha de la captura | Operación |
| Imágenes de contenedor | 30 días | Fecha de publicación | Operación |
Los cuatro últimos se conservan con bloqueo de objeto en modo cumplimiento: una vez escritos no pueden modificarse ni eliminarse antes de cumplirse el período, ni siquiera con credenciales administrativas.
3. Datos de autenticación sensibles — Req 3.3.1
3.1 Mecanismo
| Control | Implementación |
|---|---|
| Almacenamiento | Exclusivamente en el gestor de secretos, con expiración nativa de 15 minutos |
| Eliminación tras autorización | Purga explícita en cuanto la operación concluye, sin esperar a la expiración |
| Barrido de expirados | Proceso periódico que elimina lo que haya superado el plazo |
| Refuerzo en lectura | El servicio comprueba el plazo también en el momento de la consulta y purga si detecta un registro vencido |
3.2 Por qué hay tres controles y no uno
El plazo se aplica en tres puntos independientes: la expiración nativa del almacén, el barrido periódico y la comprobación en cada lectura. Un dato vencido no puede devolverse aunque fallen los dos primeros, porque el tercero lo intercepta y lo purga antes de responder.
Esta redundancia es deliberada: el requisito no admite que un dato sensible sobreviva por un fallo del proceso de limpieza.
4. Número de tarjeta — evidencia de ejecución real
Es el punto donde su plan de cierre pedía demostrar una ejecución trazable y no solo la existencia del proceso.
4.1 Configuración
| Campo | Valor |
|---|---|
| Período de retención | 30 días desde la baja lógica |
| Ejecución | Diaria, 03:00 UTC |
| Registro de auditoría | Cada purga publica un evento de ciclo de vida del registro |
4.2 Ejecuciones verificadas
Extracto literal del registro del servicio, correspondiente a los dos últimos días:
2026-08-15 03:00:00 [PanPurgeService] Starting PAN purge: retention=30d, cutoff=2026-07-16
2026-08-15 03:00:00 [PanPurgeService] No cards past retention window; nothing to purge
2026-08-16 03:00:00 [PanPurgeService] Starting PAN purge: retention=30d, cutoff=2026-07-17
2026-08-16 03:00:00 [PanPurgeService] No cards past retention window; nothing to purgeEl proceso se ejecuta puntualmente, calcula y registra la fecha de corte —que avanza un día en cada ejecución, como corresponde a una ventana móvil de 30 días— y deja constancia del resultado.
«Nothing to purge» significa que no existen registros que hayan superado la ventana, no que el proceso no se ejecutara. La distinción es justamente la que su plan de cierre señalaba como necesaria, y por eso el proceso registra el inicio y la fecha de corte además del resultado.
4.3 Observación que declaramos por iniciativa propia
El planificador se ejecuta dentro de cada instancia del servicio, y el servicio tiene dos instancias. En consecuencia, la purga se ejecuta dos veces al día, una por instancia, como se aprecia en el registro anterior.
No tiene efecto sobre el dato —la operación de borrado es idempotente y la segunda ejecución no encuentra nada que eliminar—, pero sí disparaba dos operaciones de recuperación de espacio sobre la misma tabla, que toma un bloqueo exclusivo, y dejaba una traza confusa: dos ejecuciones registradas para un único evento de retención.
Corregido el 2026-08-16. Las instancias se coordinan ahora mediante un cerrojo de la propia base de datos: solo la que lo obtiene ejecuta la purga, y las demás lo registran y se abstienen. Se eligió ese mecanismo, y no un componente externo de elección de instancia, porque la base ya es el punto de serialización natural de este trabajo y no añade una pieza que pueda fallar por su cuenta.
Verificado con cinco pruebas automatizadas que cubren los casos que importan: que solo una instancia ejecuta, que el cerrojo se libera aunque la purga falle —lo que impide que un error deje la purga bloqueada indefinidamente en todas las instancias— y que nunca se libera un cerrojo que no se obtuvo.
5. Copias de seguridad y registros
| Repositorio | Contenido | Retención | Inmutabilidad |
|---|---|---|---|
| Copias de base de datos | Volcados cifrados | 3 años | Bloqueo en modo cumplimiento |
| Registros de auditoría | Traza de eventos | 3 años | Bloqueo en modo cumplimiento |
| Material criptográfico | Respaldo del gestor de claves | 7 años | Bloqueo en modo cumplimiento |
| Estado de infraestructura | Configuración declarada | 90 días | Bloqueo en modo cumplimiento |
El envío se realiza mediante procesos programados que verifican la integridad de lo almacenado releyendo la huella criptográfica del objeto antes de eliminar la copia local. Ningún dato se borra localmente sin confirmar previamente que el destino lo conserva íntegro.
6. Elementos que NO podemos demostrar técnicamente
Se relacionan con transparencia. No se declaran como ejecutados.
| # | Elemento solicitado | Situación |
|---|---|---|
| 1 | Matriz de información protegida, en versión controlada y firmada | Pendiente. Documento organizativo con responsable y fecha de revisión |
| 2 | Certificado de destrucción de medios físicos | Pendiente, o declaración formal de no aplicabilidad si no existen medios en alcance |
| 3 | Acta de la prueba anual de efectividad | Pendiente. No consta ejecutada |
| 4 | Prueba controlada de fallo del proceso de eliminación | Pendiente. Debe ejecutarse en entorno no productivo y documentarse |
| 5 | Matriz de responsabilidades | Pendiente. Documento organizativo |
| 6 | Reporte mensual de purga | Pendiente. El dato existe en los registros; falta consolidarlo en un informe periódico |
Sobre el punto 4, y por coherencia con lo que hemos encontrado en otras revisiones: el proceso registra su ejecución pero no alerta si deja de ejecutarse. Un fallo silencioso produciría una retención indefinida sin que nadie lo advirtiera. Es una brecha real y la declaramos como tal; el mecanismo de alerta se implantará junto con el informe periódico del punto 6.
7. Compromiso
| Elemento | Fecha |
|---|---|
| Coordinación de la purga entre instancias (§4.3) | Completado el 2026-08-16 |
| Alerta ante ausencia de ejecución e informe periódico (§6.4, §6.6) | A convenir |
| Documentos organizativos (§6.1, §6.5) | A convenir |
| Prueba anual de efectividad (§6.3) | A convenir; ofrecemos ejecutarla con supervisión del equipo evaluador |
8. Evidencia de respaldo publicada
Todos los documentos están accesibles en el portal de cumplimiento.
| Documento | Qué aporta |
|---|---|
| Procedimiento de retención y eliminación | Procedimiento formal DOC-DATA-RET-01 |
| Matriz de información protegida | Tipo de dato, ubicación, protección y período |
| Evidencia Q25 — retención y eliminación | Paquete de evidencia técnica original |
| Enmascaramiento de PAN | Minimización del dato en presentación y registros |
| POL-012 · Clasificación y protección de datos | Política que enmarca los períodos |
Nota sobre la lectura de estos documentos: algunos incluyen un aviso de corrección del direccionamiento de red, corregido el 2026-08-16. No afecta a los períodos de retención ni a los mecanismos de eliminación descritos aquí, pero se señala para que no sorprenda al abrirlos.
Firma
- Elaborado: Gabriel Ureña Chacón — CTO Fintrix Pay
- Fecha: 2026-08-16