DSAR, supresión y evidencias ISO 27001 en 2026

El correo llegó a la bandeja de entrada de Sarah a las 9:03.

No era la primera solicitud de acceso del interesado que recibía su empresa SaaS en rápido crecimiento. Era la primera que parecía una auditoría pública.

El remitente era un exempleado, ahora activista de la privacidad. La solicitud citaba artículos del GDPR por número y exigía todos los datos personales, la limitación inmediata del tratamiento, una lista de todos los servicios de terceros que conservaban sus datos y una prueba verificable de la supresión en los sistemas de producción y de copia de seguridad. Un periodista estaba en copia.

En cuestión de minutos aparecieron las brechas. Ingeniería advirtió que una “supresión real” en una base de datos multiinquilino podía afectar a otros clientes. Marketing intentaba deshacer el entramado de datos de usuario en plataformas de analítica. Legal identificó un asunto laboral sin resolver. Seguridad temía que los registros pudieran revelar lógica de detección o datos de otra persona. Soporte tenía registros asociados a dos direcciones de correo. Finanzas tenía facturas bajo una tercera.

El reloj ya había empezado a correr.

Ese escenario ya no es inusual. En 2026, los derechos de los interesados no son un problema de buzón de privacidad. Son un proceso organizativo controlado que depende de inventarios de activos, decisiones sobre base jurídica, verificación de identidad, control de acceso, reglas de conservación, retención legal, coordinación con proveedores, comunicación segura, evidencias de supresión y registro de eventos preparado para auditoría.

El GDPR indica a las organizaciones qué derechos tienen las personas. ISO/IEC 27001:2022 proporciona a los equipos de seguridad y cumplimiento la disciplina de sistema de gestión necesaria para demostrar que esos derechos se gestionan de forma coherente, segura y repetible.

Para los CISO, responsables de cumplimiento, responsables de privacidad y propietarios de negocio, el objetivo no es generar más documentación. El objetivo es construir un único flujo de trabajo fiable de DSAR, supresión y limitación que produzca las evidencias exigidas por el GDPR, las auditorías ISO/IEC 27001:2022 y expectativas de aseguramiento más amplias conforme a NIS2, DORA, NIST CSF 2.0 y COBIT 2019.

Por qué la gestión ad hoc de DSAR falla bajo presión

La mayoría de los fallos en DSAR no se deben a malas intenciones. Se deben a la fragmentación.

Una organización puede disponer de un aviso de privacidad, un buzón del DPO y una cláusula GDPR en los contratos con proveedores, y aun así tener dificultades para responder preguntas operativas básicas:

• ¿Quién valida la identidad del solicitante?
• ¿Qué entidad jurídica actúa como responsable o encargado del tratamiento?
• ¿Qué sistemas deben revisarse?
• ¿Quién es propietario de cada sistema?
• ¿Qué datos están dentro del alcance?
• ¿Qué datos deben expurgarse antes de su comunicación?
• ¿Qué datos no pueden suprimirse por motivos fiscales, de auditoría, litigio, prevención del fraude u obligación legal?
• ¿Cómo se aplica técnicamente la limitación del tratamiento?
• ¿Qué proveedores deben apoyar la búsqueda, exportación, supresión o limitación?
• ¿Qué evidencias demuestran que la solicitud se gestionó dentro de plazo?
• ¿Qué ocurre si la DSAR revela una brecha de seguridad de los datos personales?

El GDPR Article 5 exige que los datos personales se traten de forma lícita, leal y transparente, se recojan con fines determinados, se limiten a lo necesario, se mantengan exactos, se conserven durante no más tiempo del necesario y se protejan mediante medidas técnicas y organizativas apropiadas. El Article 5(2) explicita la responsabilidad proactiva: el responsable del tratamiento debe poder demostrar el cumplimiento. El Article 4 define ampliamente el tratamiento, incluyendo la recogida, almacenamiento, uso, comunicación, limitación, supresión y destrucción.

Esto significa que el propio proceso DSAR es una actividad de tratamiento. Debe estar controlado.

El GDPR Article 3 también es relevante para empresas en la nube, SaaS, fintech y digitales fuera de la UE. Si ofrece bienes o servicios a personas en la Unión, controla su comportamiento o trata datos personales en el contexto de un establecimiento en la UE, el GDPR puede aplicarse incluso cuando las operaciones estén externalizadas o la infraestructura sea global.

ISO/IEC 27001:2022 aporta estructura a esta realidad. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, las partes interesadas, los requisitos, el alcance del SGSI y los procesos que interactúan. Un interesado es una parte interesada. Los derechos del GDPR son requisitos. Las aplicaciones SaaS, proveedores de identidad, plataformas de analítica, herramientas de soporte, almacenes de datos y copias de seguridad en la nube son procesos que interactúan. Un flujo de trabajo DSAR pertenece dentro del SGSI, no junto a él.

Los tres derechos de los interesados que generan más presión

El acceso, la supresión y la limitación exponen la mayor brecha entre la promesa legal y la capacidad operativa.

El GDPR Article 6 es central en esta lógica de decisión. No se puede tratar, conservar, comunicar ni denegar la supresión sin comprender la base jurídica. El Article 9 eleva el umbral para categorías especiales de datos personales, como datos de salud, datos biométricos utilizados para la identificación única o datos que revelan características sensibles. En un entorno SaaS de 2026, esto puede afectar a la incorporación, la verificación de identidad, la monitorización del fraude, los adjuntos de soporte al cliente y los registros de empleados.

La política empresarial de Clarysec Data Protection and Privacy Policy [P17] formula la obligación directamente. En la cláusula 3.6 de Objetivos, exige a la organización:

Respetar los derechos de los interesados, incluidos el acceso, la rectificación, la supresión, la limitación, la portabilidad, la oposición y la protección frente a decisiones automatizadas.

Ese objetivo solo se vuelve auditable cuando se vincula a propietarios, registros, flujos de trabajo, controles y evidencias.

Empiece donde empiezan los auditores: alcance, partes interesadas y propiedad

En Zenith Blueprint: hoja de ruta de 30 pasos para auditores [ZB], la fase de fundamentos y liderazgo del SGSI, paso 2, se centra en las necesidades de las partes interesadas y el alcance del SGSI. Para el GDPR, el Blueprint identifica las expectativas regulatorias como:

Reguladores de la UE
(GDPR)

Tratamiento lícito de datos
personales, notificación de brechas en 72 h,
derechos de los interesados

Designar un delegado de protección de datos, establecer
un proceso de respuesta a brechas, procedimientos para
gestionar solicitudes de datos.

Este es el punto de partida correcto. Antes de automatizar tickets o configurar portales, defina el alcance del tratamiento de derechos de los interesados:

1. ¿Qué entidades jurídicas actúan como responsable, corresponsable o encargado del tratamiento?
2. ¿Qué productos, servicios y territorios están dentro del alcance?
3. ¿Qué categorías de interesados existen, como clientes, empleados, usuarios de prueba, prospectos, proveedores, visitantes del sitio web o usuarios de la aplicación?
4. ¿Qué sistemas, repositorios y proveedores conservan datos personales?
5. ¿Qué roles aprueban la comunicación, denegación, supresión, limitación o escalado?
6. ¿Qué métricas se reportan a la dirección?

Las cláusulas 5.1 a 5.3 de ISO/IEC 27001:2022 exigen liderazgo, alineación de políticas, recursos y responsabilidades asignadas. Esto se alinea directamente con la responsabilidad proactiva del GDPR.

La Data Protection and Privacy Policy [P17], cláusula 6.4.1 de Requisitos de implantación de la política, establece:

El Data Protection Officer (DPO) debe mantener procesos documentados para la recepción, validación, seguimiento y respuesta de las solicitudes de los interesados (DSR).

Para pymes, la Data Protection and Privacy Policy - SME [P17S] de Clarysec utiliza una propiedad ajustada al tamaño de la organización. La cláusula 5.2.1 de Requisitos de gobernanza establece:

El Coordinador de Privacidad debe mantener un registro de todas las actividades de tratamiento de datos personales, incluidas las categorías de datos, la finalidad, la base jurídica y los períodos de conservación

Ese registro de tratamiento es el núcleo operativo de la preparación para DSAR. Si está incompleto, el equipo DSAR busca por memoria, mensajes de Slack y conocimiento tribal. Si es preciso, el equipo busca por actividad de tratamiento, categoría de datos, propietario del sistema, proveedor y regla de conservación.

El flujo de trabajo DSAR de Clarysec: de la recepción al cierre

Un flujo de trabajo DSAR preparado para auditoría debe ser lo bastante simple para ejecutarse bajo presión, pero lo bastante controlado para resistir a un regulador, una revisión de aseguramiento de cliente o una auditoría ISO/IEC 27001:2022.

1. Recepción y acuse de recibo

Las solicitudes deben entrar por un canal controlado, como un buzón de privacidad, un portal, un formulario de soporte o una cola de entrada legal. El personal debe reconocer las solicitudes formuladas en lenguaje corriente. Una persona no necesita escribir “DSAR” para ejercer un derecho. “¿Qué datos tienen sobre mí?” o “eliminen mi perfil” puede ser suficiente para activar el flujo de trabajo.

La Data Protection and Privacy Policy - SME [P17S], cláusula 6.5.2 de Requisitos de implantación de la política, establece un nivel de servicio claro:

El Coordinador de Privacidad debe acusar recibo de las solicitudes en un plazo de 3 días laborables y responder en un plazo de 30 días

El acuse de recibo debe incluir la referencia de la solicitud, la aclaración del alcance si es necesaria, las instrucciones de verificación de identidad y el plazo previsto de respuesta.

2. Verificación de identidad y comprobación de autoridad

Una DSAR puede convertirse en una brecha de seguridad de los datos personales si la información se envía a la persona equivocada. La verificación debe ser proporcionada y no debe recoger nuevos datos personales excesivos. Utilice portales autenticados cuando sea posible. Para antiguos usuarios, valide contra datos de cuenta conocidos. Para empleados, coordine con RR. HH. Para representantes, exija prueba de representación.

Conserve evidencias del método de verificación, la fecha de finalización, el aprobador, cualquier información adicional solicitada y la decisión si la verificación falla.

3. Clasificar la solicitud

Un solo mensaje puede contener varios derechos. Clasifique cada uno por separado, porque el acceso, la supresión, la limitación, la oposición y la portabilidad requieren lógicas de decisión y evidencias distintas. Marque también posibles reclamaciones, asuntos laborales, datos de menores, datos de categorías especiales y posibles brechas de seguridad de los datos personales.

4. Buscar en el inventario, no solo en los sistemas evidentes

Aquí es donde ISO/IEC 27001:2022 se vuelve práctico. Zenith Blueprint [ZB], fase Controles en acción, paso 22, advierte que el alcance del inventario es más amplio de lo que muchas organizaciones esperan:

El alcance de este inventario es más amplio de lo que la mayoría cree. Debe incluir:

✓ Activos físicos: portátiles, servidores, teléfonos, cintas de copia de seguridad, soportes extraíbles, registros
impresos.
✓ Activos digitales: documentos, conjuntos de datos, repositorios, correos electrónicos, código fuente, archivos
almacenados en la nube.
✓ Activos lógicos: cuentas de usuario, credenciales, claves, licencias de software, interfaces de programación de aplicaciones.
✓ Activos relacionados con servicios: plataformas SaaS, servicios de seguridad gestionados, almacenamiento
externalizado.
✓ Personas como activos: no en un sentido cosificado, sino en términos de responsabilidades asignadas,
acceso y exposición a la información derivada del rol.

El paso 22 también explica la propiedad:

Cada activo debe tener un propietario definido, no la persona que lo utiliza, sino quien rinde cuentas
de su uso, protección y ciclo de vida. La propiedad es esencial para la alineación de controles: quién clasifica
el activo (5.10), quién decide su nivel de acceso (8.3), quién gestiona su eliminación (8.10), quién garantiza
su devolución (5.9 se solapa sutilmente con los procedimientos de devolución de activos).

En Zenith Controls: guía de cumplimiento transversal [ZC], el control 5.9 de ISO/IEC 27002:2022, Inventario de información y otros activos asociados, se trata como un control preventivo que respalda la confidencialidad, integridad y disponibilidad. Su concepto de ciberseguridad es Identificar, su capacidad operativa es Gestión de activos y sus dominios de seguridad incluyen Gobernanza, Ecosistema y Protección.

Para las DSAR, esto significa que el inventario no es una hoja de cálculo de TI. Es el mapa que indica a privacidad, legal y seguridad dónde pueden existir datos personales.

5. Revisar, expurgar y aprobar la comunicación

Una respuesta DSAR no debe ser una exportación sin procesar. La revisión debe proteger los datos personales de otras personas, la información confidencial de la organización, el secreto profesional, los datos sensibles desde el punto de vista de seguridad, las señales de fraude y los datos fuera del alcance de la solicitud.

La aprobación debe basarse en riesgos. Las respuestas rutinarias de acceso pueden ser aprobadas por el Coordinador de Privacidad o el DPO. Las solicitudes que involucren empleados, litigios, datos de categorías especiales, menores, fraude, registros de seguridad o grandes exportaciones deben implicar a los responsables de legal, RR. HH. o seguridad.

6. Entregar de forma segura

No adjunte archivos grandes sin cifrar a un correo electrónico. Utilice portales autenticados, archivos cifrados con entrega separada de contraseña o enlaces de transferencia segura con caducidad y registro de accesos. Registre el método de entrega, la fecha, la cuenta destinataria, la fecha de caducidad y la confirmación cuando esté disponible.

7. Cerrar con evidencias

La Data Protection and Privacy Policy [P17], cláusula 6.4.3, es explícita:

Todas las acciones realizadas deben registrarse con fines de auditoría, incluidas las decisiones de denegar solicitudes.

La Data Protection and Privacy Policy - SME [P17S], cláusula 6.5.4, establece:

Todas las respuestas a solicitudes de los interesados deben registrarse en un registro seguro, con acceso restringido al Coordinador de Privacidad y al DG

Una DSAR no está completa cuando se envía el correo. Está completa cuando el registro muestra la solicitud, la comprobación de identidad, las decisiones, los sistemas revisados, la respuesta, las excepciones, las aprobaciones, la entrega y el cierre.

La supresión es destrucción controlada, no un botón de eliminar

Las solicitudes de supresión revelan si la privacidad se ha diseñado dentro de los sistemas o se ha añadido después del lanzamiento.

La política empresarial de Clarysec Data Retention and Disposal Policy [P14], cláusula 4.3.3 de Roles y responsabilidades, asigna responsabilidad al rol que:

Responde a las solicitudes de supresión y garantiza la eliminación oportuna y verificable de los datos personales cuando proceda.

La frase “cuando proceda” es crítica. La supresión conforme al GDPR no es absoluta. Las organizaciones pueden necesitar conservar datos por obligaciones legales, auditoría, fiscalidad, obligaciones regulatorias, prevención del fraude, seguridad, litigios o la formulación, ejercicio o defensa de reclamaciones. El flujo de trabajo debe incluir una decisión de conservación lícita y de excepción.

Zenith Blueprint [ZB], fase Controles en acción, paso 19, explica el control 8.10 de ISO/IEC 27002:2022, Eliminación de información, en términos operativos:

Este control garantiza que los datos no se conserven durante más tiempo del necesario y que, cuando ya no sean
necesarios, deban eliminarse de forma segura y fiable. Muchas organizaciones acumulan grandes
volúmenes de datos con el tiempo, pero sin un proceso claro de eliminación, esos datos pueden permanecer inactivos y
desprotegidos, aumentando silenciosamente el riesgo de exposición, brecha de seguridad o incumplimiento regulatorio.

También advierte:

No olvide las copias de seguridad y los sistemas archivados; estos suelen conservar datos históricos mucho más allá de su
valor operativo. Las políticas de eliminación deben extenderse a:

✓ Ajustes de conservación de copias de seguridad,
✓ Ciclos de vida de instantáneas,
✓ Repositorios de correo electrónico o documentos archivados.

Y cierra con evidencias:

El propio proceso de eliminación debe quedar registrado y, en el caso de datos de alto riesgo o regulados,
revisado o aprobado. Esto garantiza la trazabilidad y protege frente a la destrucción accidental o
no autorizada de registros valiosos.

En Zenith Controls [ZC], el control 8.10 de ISO/IEC 27002:2022, Eliminación de información, se mapea como un control preventivo centrado en la confidencialidad, alineado con el concepto de ciberseguridad Proteger y vinculado a las capacidades operativas de Protección de la información y Legal y Cumplimiento.

Para arquitecturas en la nube complejas, el borrado criptográfico puede ser adecuado cuando se diseña correctamente. Si los datos personales están cifrados con una clave específica del interesado o del inquilino, destruir la clave puede hacer que los datos sean permanentemente inaccesibles, incluso cuando queden remanentes cifrados en copias de seguridad hasta la rotación programada. Esto debe diseñarse, documentarse, probarse y aprobarse cuidadosamente. No es una solución alternativa para una arquitectura de eliminación deficiente.

Por tanto, la preparación de las aplicaciones es esencial. La Application Security Requirements Policy - SME [P09S] de Clarysec, cláusula 6.5.1.3, exige que las aplicaciones:

permitan la exportación y eliminación seguras de datos personales cuando sea legalmente exigible (por ejemplo, GDPR Article 17 – derecho de supresión).

Si los equipos de producto no incorporan capacidades de exportación y eliminación, los equipos de privacidad se ven forzados a utilizar scripts de base de datos, tickets con proveedores y trabajo manual incoherente.

Retención legal y suspensión de la eliminación

Un flujo de trabajo de supresión maduro debe incluir una vía de “no eliminar”. Esto no es una excusa para ignorar la supresión. Es una excepción controlada.

La Data Retention Policy and Secure Disposal Policy - SME [P14S] de Clarysec para pymes, cláusula 5.4 de Requisitos de gobernanza, establece:

Los datos sujetos a retención legal y suspensión de la eliminación (por ejemplo, en caso de litigio, auditoría o investigación) deben identificarse claramente en el sistema y protegerse frente a la eliminación, incluso si el período de conservación programado ha vencido.

La Data Retention and Disposal Policy [P14], cláusula 6.4.1, refleja el mismo principio:

Si se emite una retención legal y suspensión de la eliminación (por ejemplo, por litigio, investigación o auditoría pendiente), los datos que de otro modo estarían sujetos a destrucción deben preservarse más allá de su período normal de conservación.

Los auditores quieren ambos lados de la historia: evidencias de eliminación oportuna y evidencias de conservación justificada.

Limitación del tratamiento: el derecho subestimado

Las solicitudes de limitación no siempre requieren eliminación. Exigen que la organización limite el tratamiento activo mientras conserva los datos en condiciones controladas.

Ejemplos comunes incluyen:

• Un cliente impugna la exactitud y pide que se deje de utilizar el dato mientras se verifica.
• Un exempleado se opone al tratamiento, pero el registro es necesario para reclamaciones.
• Un usuario solicita la supresión, pero deben conservarse datos mínimos para mantener una lista de supresión.
• Una investigación de fraude requiere conservación, pero no uso operativo normal.

Un flujo de trabajo práctico de limitación debe incluir una decisión legal, una marca en el sistema, un ajuste de control de acceso, supresión de marketing, exclusión de analítica, instrucción al proveedor, revisión periódica y evidencias de excepción.

En Zenith Controls [ZC], el control 5.34 de ISO/IEC 27002:2022, Privacidad y protección de la información de identificación personal (PII), se trata como un control preventivo que respalda la confidencialidad, integridad y disponibilidad. Se mapea con Identificar y Proteger, con capacidades operativas de Protección de la información y Legal y Cumplimiento.

Zenith Blueprint [ZB], fase Controles en acción, paso 23, resume la prueba de auditoría:

Confirme que su organización ha implantado medidas de privacidad (5.34) alineadas con
los requisitos legales aplicables. Verifique la clasificación de la información de identificación personal (PII), los controles de acceso
adecuados, las prácticas seguras de tratamiento y la formación de concienciación. Valide si las solicitudes de acceso de los interesados, la
eliminación de datos o los registros de tratamiento cuentan con soporte operativo, no solo en la política.

La frase clave es “cuentan con soporte operativo, no solo en la política”.

Mapeo de flujos de trabajo DSAR con evidencias de ISO/IEC 27001:2022

ISO/IEC 27001:2022 no sustituye al GDPR. Organiza las evidencias.

Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, criterios de aceptación del riesgo, propietarios del riesgo, selección de controles, una Declaración de Aplicabilidad y un Plan de Tratamiento de Riesgos. Los riesgos de DSAR incluyen comunicación no autorizada, incumplimiento de plazos, supresión incompleta, conservación ilícita, verificación de identidad excesiva, falta de cooperación de proveedores e incapacidad para limitar el tratamiento.

La cláusula 8.1 exige que las organizaciones planifiquen, implanten y controlen los procesos del SGSI, conserven evidencias documentadas, controlen cambios y aseguren que los procesos, productos y servicios proporcionados externamente y relevantes para el SGSI estén controlados. Esto encaja con las operaciones DSAR porque las solicitudes atraviesan funciones internas y encargados externos.

Un paquete de evidencias sólido incluye el procedimiento DSR, el registro DSR, el registro de actividades de tratamiento, el inventario de activos, el calendario de conservación de datos, el registro de retención legal, el procedimiento de verificación de identidad, la guía de expurgo, el método de comunicación segura, el procedimiento de supresión, el procedimiento de limitación, el playbook de proveedores, el registro de excepciones, los registros de formación, los resultados de auditoría interna y los informes de revisión por la dirección.

Un flujo de trabajo práctico para acceso, supresión y limitación

Este flujo de trabajo convierte la crisis de Sarah en un proceso auditable. Cada etapa tiene un propietario, una base de control y evidencias.

Valor de cumplimiento transversal más allá del GDPR

Un flujo de trabajo DSAR tiene su raíz en el GDPR, pero los mismos controles respaldan marcos más amplios.

El NIS2 Article 20 convierte la ciberseguridad en una responsabilidad de gestión para entidades esenciales e importantes. El Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidas análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, evaluación de la eficacia, higiene cibernética, formación, control de acceso, gestión de activos, autenticación y comunicaciones seguras. Las DSAR dependen de muchas de esas mismas capacidades.

DORA se aplica desde el 17 de enero de 2025 a muchas entidades financieras y establece requisitos uniformes de gestión del riesgo de las TIC, notificación de incidentes, pruebas de resiliencia y riesgo de terceros de TIC. Los Articles 5 y 6 exigen gobernanza y gestión del riesgo de las TIC documentada. Los Articles 17 a 20 abordan la detección de incidentes, clasificación, escalado, comunicación y cierre. Los Articles 24 a 30 abordan pruebas de resiliencia, riesgo de terceros de TIC, registros de servicios, derechos de auditoría, ubicación de datos, asistencia en incidentes y estrategias de salida. Una fintech que gestione DSAR mediante plataformas en la nube debe alinear la gestión de solicitudes de privacidad con su registro de servicios de TIC.

NIST CSF 2.0 ayuda a traducir el mismo trabajo en resultados de ciberseguridad. GOVERN aborda requisitos legales, regulatorios y contractuales, estrategia de riesgo, roles, política y supervisión. IDENTIFY y PROTECT se alinean estrechamente con la visibilidad de activos, la clasificación de datos, el control de acceso, la eliminación, la gobernanza de proveedores y la protección de la privacidad.

COBIT 2019 plantea preguntas de gobernanza. ¿Quién es propietario del proceso? ¿Qué objetivos se han definido? ¿Cómo se mide el desempeño? ¿Cómo se aprueban las excepciones? ¿Cómo se obtiene aseguramiento? Las evidencias de DSAR pueden respaldar objetivos como APO13 Gestionar la seguridad, APO14 Gestionar los datos y DSS06 Gestionar los controles de procesos de negocio.

La perspectiva del auditor

No cree evidencias separadas para cada marco. Cree un flujo de trabajo DSAR fiable y mapee bien sus evidencias.

Métricas DSAR que la dirección debe ver

La dirección no puede supervisar lo que no ve. Entre las métricas útiles se incluyen el volumen de solicitudes por tipo de derecho, el tiempo medio de acuse de recibo, el tiempo medio de cierre, el cumplimiento de plazos, las tasas de aclaración de identidad, las excepciones de eliminación, los casos de retención legal, los tiempos de respuesta de proveedores, las denegaciones parciales, los incidentes identificados durante la gestión y las acciones de remediación abiertas.

Estas métricas muestran si los derechos de los interesados están operativamente sanos o dependen de esfuerzos heroicos.

Brechas comunes de preparación para DSAR

Clarysec observa habitualmente las mismas debilidades en SaaS, fintech, servicios profesionales y pymes cloud-first:

• No hay propietario para cada sistema que contiene datos personales
• El registro de tratamiento no está alineado con el uso real de SaaS
• Las plataformas de marketing, analítica y almacén de datos se excluyen de las búsquedas
• No existe un estándar documentado de verificación de identidad
• No hay revisión de expurgo antes de la comunicación
• La eliminación en producción se realiza sin tratamiento de copias de seguridad
• No hay comprobación de retención legal antes de la supresión
• La limitación se gestiona manualmente sin marca en el sistema
• Los contratos con proveedores no incluyen términos de asistencia DSAR
• Las denegaciones y denegaciones parciales no se documentan
• No hay muestreo de auditoría interna sobre DSAR completadas
• El personal de primera línea no está formado para reconocer solicitudes

Su lista de verificación de preparación para DSAR en 2026

Utilícela como prueba de madurez:

• ¿Tenemos un proceso documentado de recepción, validación, seguimiento y respuesta de DSR?
• ¿Acusamos recibo de las solicitudes dentro de un SLA interno definido?
• ¿Mantenemos un registro DSR seguro con acceso restringido?
• ¿Disponemos de un registro actualizado de actividades de tratamiento con categorías, finalidades, bases jurídicas y períodos de conservación?
• ¿Conocemos todos los sistemas, plataformas SaaS, repositorios y proveedores que pueden conservar datos personales?
• ¿Tiene cada activo relevante un propietario responsable?
• ¿Podemos exportar datos personales de forma segura?
• ¿Podemos eliminar datos personales de forma segura cuando sea legalmente exigible?
• ¿Podemos limitar el tratamiento técnica o procedimentalmente?
• ¿Comprobamos la retención legal antes de la eliminación?
• ¿Documentamos decisiones de denegación, denegación parcial y excepción?
• ¿Los contratos con proveedores respaldan la asistencia DSAR?
• ¿Probamos el flujo de trabajo mediante auditoría interna o ejercicios de mesa?
• ¿Reportamos el desempeño de DSAR a la dirección?
• ¿Mapeamos los controles DSAR dentro del tratamiento de riesgos de ISO/IEC 27001:2022 y la Declaración de Aplicabilidad?

Si varias respuestas son “no de forma consistente”, la siguiente solicitud puede exponer la brecha.

Convierta los derechos de los interesados en evidencias preparadas para auditoría

En 2026, los derechos de los interesados requieren algo más que buenas intenciones y un buzón de privacidad. Requieren un flujo de trabajo capaz de encontrar datos, validar identidades, tomar decisiones lícitas, coordinar proveedores, proteger la comunicación, ejecutar la supresión, aplicar la limitación y conservar evidencias.

Clarysec ayuda a las organizaciones a construir ese flujo de trabajo sin crear una burocracia de cumplimiento paralela. Empiece con Zenith Blueprint para situar los derechos de los interesados en la fase y los pasos correctos del SGSI. Utilice la Data Protection and Privacy Policy, la Data Protection and Privacy Policy - SME, la Data Retention and Disposal Policy, la Data Retention Policy and Secure Disposal Policy - SME y la Application Security Requirements Policy - SME de Clarysec para definir la propiedad y las reglas operativas.

Después utilice Zenith Controls para mapear los controles 5.9, 5.34 y 8.10 de ISO/IEC 27002:2022 con evidencias de cumplimiento transversal para el aseguramiento de GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 y COBIT 2019.

Si quiere saber si sus flujos de trabajo de DSAR, supresión y limitación superarían una auditoría mañana, Clarysec puede ayudarle a probar el proceso, cerrar las brechas y construir el paquete de evidencias antes de que llegue la siguiente solicitud. Descargue las plantillas de políticas de Clarysec correspondientes o reserve una evaluación de preparación para DSAR para pasar de una respuesta reactiva a operaciones de privacidad controladas y preparadas para auditoría.