IT

Eliminar de verdad los datos en la nube: ¿cómo lo sabes con certeza?

16 de mayo de 2026 · 8 min de lectura · DeSnipperaar

El botón de eliminar en la nube se siente definitivo. Archivo fuera de la interfaz, papelera vaciada, listo. Pero detrás de esa única acción hay distintos sistemas que aplican cada uno su propio ritmo a la hora de borrar realmente los datos. Replicación entre centros de datos, copias de seguridad diarias, sistemas de registro, instantáneas de monitorización. Todas son copias que no se eliminan automáticamente con el borrado. Para las organizaciones responsables este es un tema importante en la política de retención y al retirar a un proveedor de nube.

Tres capas en las que actúa un «eliminar»

Capa 1. La aplicación

Lo que ves como usuario. Un documento desaparece de Drive, un registro se «archiva» en un CRM, un buzón se vacía. En esta capa casi siempre ocurre que los datos solo se hacen invisibles. En la base de datos subyacente el registro sigue existiendo, a menudo con una marca de «deleted».

Capa 2. La base de datos

Los registros con marca de borrado se eliminan de verdad de forma periódica, a veces tras 30 días, a veces tras 90, a veces solo en una acción manual de limpieza. Las bases de datos suelen usar «soft delete» para poder recuperar tras un error y mantener intactos los registros de auditoría.

Capa 3. El almacenamiento físico

Aquí está la destrucción realmente ilegible. En los SSD de un centro de datos el almacenamiento físico solo se sobrescribe cuando llegan datos nuevos a ocupar su lugar. Hasta ese momento los datos antiguos quedan en celdas que el proveedor ya no considera ocupadas pero que siguen siendo físicamente legibles. Cómo encaja aquí la diferencia entre borrar y destruir lo lees en ese artículo. Para la nube hay además una cuarta capa, la replicación.

Qué hace la replicación

Los proveedores de nube replican los datos automáticamente entre varios centros de datos para garantizar la fiabilidad. Eso significa que un borrado debe propagarse por todas las réplicas. AWS, GCP y Azure documentan que esto ocurre en segundos o minutos para los datos en vivo. Pero hay matices.

• Las copias de seguridad tienen su propia retención y a menudo quedan fuera de la cadena de borrado.
• Las instantáneas que se crean por motivos operativos se conservan según un ciclo aparte.
• Los registros y la monitorización contienen a menudo fragmentos de datos en rutas de URL, payloads o trazas de error.
• Las capas de caché pueden retener copias durante un tiempo breve, a veces en los nodos perimetrales de un CDN.

Borrado criptográfico: un atajo elegante

El enfoque moderno en la nube empresarial se llama crypto-erasure. Los datos se almacenan cifrados. Al eliminarlos se destruye la clave en lugar de los datos en sí. Sin clave, los datos cifrados son efectivamente aleatorios, algo que la NIST 800-88 acepta como una forma de Purge.

Ventaja. El borrado es instantáneo, sin importar cuántas réplicas existan, porque la clave es un único objeto. Desventaja. Confías en que el proveedor destruye realmente la clave y no guarda una copia en un archivo de gestión de claves. Para la mayoría de clientes y casos de uso esa relación de confianza es aceptable. Para sectores muy regulados es motivo para exigir garantías adicionales. Lee más sobre las normas NIST y DIN.

Qué debe fijar la política de retención

1. Qué datos corresponden a qué plazo de conservación. Consulta la guía rápida de plazos de conservación RGPD para los plazos legales.
2. Cuánto tiempo existen las copias de seguridad y qué significa eso para las solicitudes de «derecho al olvido».
3. Qué acaba en registros y pistas de auditoría y cuánto tiempo se conservan.
4. Cómo gestiona tu proveedor los borrados. ¿Borrado síncrono en todos los centros de datos o asíncrono? ¿Recibes prueba de ello?
5. Las posibilidades de borrado criptográfico por servicio.

Qué debe entregar tu proveedor

• Una declaración de borrado de datos bajo petición, con fecha y volumen.
• Un proceso conforme a NIST 800-88 para la capa física (sustitución de discos, secure-erase).
• Documentación del ciclo de copias de seguridad y de cómo se propagan en él los borrados.
• Un SLA sobre el tiempo de borrado, no solo sobre la replicación.
• Cláusulas contractuales tipo bajo el RGPD en la nube transfronteriza.

Un botón de eliminar es una instrucción, no una destrucción. Pide a tu proveedor de forma explícita la prueba de que la instrucción también se ejecuta a nivel físico.

Cuándo la nube no basta

Para algunas categorías de datos la destrucción en la nube no es suficiente. Los expedientes de pacientes, los ámbitos de secreto profesional o el secreto de Estado deben estar en soportes cuya destrucción física puedas demostrar. El borrado criptográfico es entonces insuficiente. Quieres ver que el propio disco se ha triturado. Para el hardware on-premises al final de su vida útil esa es la ruta estándar, lee sobre cómo se tritura un disco duro.

Plan de acción práctico para una retirada

1. Inventaría qué datos hay en la nube y qué plazos de conservación se les aplican.
2. Determina si el borrado criptográfico basta para tu clasificación o si hace falta destrucción física.
3. Solicita a tu proveedor una declaración de borrado de datos con fecha y alcance.
4. Para los datos fuera de la nube (archivos de exportación, copias propias en USB o HDD), destruye físicamente.
5. Conserva la declaración y el certificado en tu registro de actividades de tratamiento.

---

¿Tu organización trabaja en una retirada de la nube? Escríbenos a través de desnipperaar.nl sobre los restos físicos de tus copias on-premise.