La Ley 2/2023 permite tratar datos personales del canal de denuncias por obligación legal (art. 6.1.c RGPD), pero limita acceso, finalidad y conservación con más severidad que otras aplicaciones corporativas. Tres errores frecuentes: base jurídica incorrecta, retenciones mal entendidas y acceso desbordado.
Un canal interno maneja algunos de los datos más delicados que puede recibir una empresa: acusaciones, conflictos laborales, conductas potencialmente delictivas, identidad de testigos, información financiera y, en ocasiones, datos de salud o de otras categorías especialmente protegidas.
Por eso la pregunta no es "¿cumple RGPD el proveedor?". Esa frase, sola, sirve de poco.
Hay que mirar qué datos entran, por qué base jurídica se tratan, quién puede verlos y cuánto tiempo permanecen en cada parte del sistema.
Cuando lo planteamos en Consulplan vimos enseguida una diferencia entre un canal convencional y cualquier otra aplicación corporativa: aquí dar acceso "por si acaso" es precisamente lo que no debes hacer.
Punto 1. La base jurídica no es el consentimiento
El borrador original decía que el tratamiento se basaba en el art. 6.1.e RGPD.
Para los Sistemas internos que son obligatorios conforme a los arts. 10 y 13 de la Ley 2/2023, esa afirmación es incorrecta. El art. 30.2 de la propia Ley declara lícito el tratamiento sobre la base del art. 6.1.c RGPD, es decir, cumplimiento de una obligación legal.
El matiz importa.
No estamos pidiendo al informante permiso para tratar los datos necesarios para tramitar su comunicación. Y tampoco podemos utilizar el hecho de haber recibido esos datos como permiso general para otros fines.
Si alguien proporciona una dirección de email al informar de una irregularidad, esa dirección no entra por eso en la base de marketing de la correduría.
Mi criterio aquí es deliberadamente conservador: los datos del canal deberían vivir separados de CRM, campañas comerciales, sistemas de RRHH generales y herramientas analíticas que no sean necesarias para gestionar las comunicaciones.
¿Puedo registrar la IP del informante?
La Ley establece que no deben recopilarse datos personales cuya pertinencia no resulte manifiesta para tratar la información concreta y que, si se obtienen accidentalmente, deben eliminarse sin dilación indebida (art. 29).
En un canal diseñado para admitir comunicaciones anónimas, normalmente no existe necesidad de registrar la IP del informante para tramitar la comunicación. Si se registra, el responsable debe poder justificar su necesidad conforme a los principios de minimización y protección de datos desde el diseño (art. 25 RGPD).
En la práctica esto plantea una pregunta incómoda para cualquier SaaS: ¿qué registra automáticamente la infraestructura aunque el formulario no lo pida?
Direcciones IP, identificadores de sesión, logs del servidor, sistemas antifraude, analítica web o servicios de terceros pueden generar información adicional.
Por eso una promesa como "anonimato" exige revisar más que la pantalla que ve el usuario: hay que revisar la config nginx, los logs del backend y qué headers viajan al proveedor.
Punto 2. Los tres meses no son una regla de borrado universal
Este es probablemente el error técnico-jurídico más repetido.
El art. 32.3 establece que los datos pueden permanecer en el Sistema únicamente durante el tiempo imprescindible para decidir si procede iniciar una investigación.
Y el art. 32.4 añade que, transcurridos 3 meses desde la comunicación sin que se hayan iniciado actuaciones de investigación, deben suprimirse del Sistema, salvo conservación como evidencia de funcionamiento. Las comunicaciones sin curso solo pueden permanecer de forma anonimizada.
¿Hay que borrar todo el día 91?
No.
"Suprimir del Sistema tras 3 meses si no se han iniciado actuaciones" no significa "borrar todo el día 91".
Si se inicia una investigación, la información necesaria puede tratarse fuera de ese entorno conforme al procedimiento y durante el tiempo legítimamente necesario.
Además, el art. 26 exige un libro-registro de las informaciones y de las investigaciones internas, con confidencialidad, y dispone que los datos se conservarán durante el tiempo necesario y proporcionado; en ningún caso por más de 10 años.
Hay, por tanto, que distinguir:
- Sistema de información → regla específica de tres meses en los supuestos del art. 32.4.
- Investigación → tratamiento mientras resulte necesario y legítimo para tramitarla.
- Libro-registro → conservación proporcionada, con límite máximo legal de diez años.
Cuando diseñamos la automatización de retenciones, esta separación es mucho más importante que poner una tarea que "borre expedientes cada 90 días".
Punto 3. El acceso tampoco es "solo el RSII"
El borrador anterior era demasiado categórico aquí.
¿Quién puede leer una denuncia?
El art. 32.1 limita el acceso, dentro de las respectivas funciones, al Responsable del Sistema y quien lo gestione directamente, al responsable de RRHH u órgano competente cuando puedan proceder medidas disciplinarias, a servicios jurídicos cuando puedan adoptarse medidas legales, a los encargados del tratamiento y al delegado de protección de datos.
La clave no es que nadie salvo el RSII pueda acceder nunca.
La clave es que nadie acceda porque sí.
En una correduría esto tiene una aplicación sencilla: pertenecer al comité de dirección no otorga automáticamente derecho a leer una denuncia.
Tampoco debería existir una cuenta genérica "admin" que permita a cualquier persona con privilegios tecnológicos consultar expedientes por comodidad.
¿Puede acceder el proveedor SaaS?
Desde una perspectiva de producto, una de las preguntas que yo haría a cualquier proveedor es: "¿puede vuestro personal leer el contenido de una comunicación?"
Si la respuesta es sí, quiero saber quién, en qué circunstancias, con qué registro, bajo qué instrucciones y con qué medidas de seguridad.
Cumplecanal aplica aislamiento técnico por cliente y controles de acceso a los expedientes. El acceso técnico del personal operador está restringido, sometido a las instrucciones del responsable y registrado mediante mecanismos auditables, conforme a las medidas descritas en el contrato de Encargo del art. 28 RGPD. La descripción arquitectónica concreta (contenedores, bases de datos, cifrado, integridad del audit log) se comparte bajo NDA en el dossier técnico de la propuesta.
Un tercero externo es encargado del tratamiento cuando gestiona el Sistema
El art. 6.4 es bastante claro: el tercero externo que gestione el Sistema tendrá la consideración de encargado del tratamiento y el tratamiento debe regirse por el contrato del art. 28.3 RGPD.
Por eso el contrato de encargo no es un documento decorativo que se adjunta después.
Debe describir realmente el tratamiento, duración, naturaleza, finalidad, tipos de datos, categorías de interesados, obligaciones y medidas aplicables conforme al RGPD.
Mi opinión como cliente de SaaS sería muy sencilla: si un proveedor vende un canal de denuncias y no me entrega claramente el acuerdo de encargo, la conversación se acaba ahí.
¿Hace falta EIPD (evaluación de impacto)?
Realizar una EIPD es prudente y será obligatoria cuando el análisis del tratamiento determine que puede entrañar un alto riesgo conforme al art. 35 RGPD y a los criterios aplicables de la AEPD.
Un canal interno de denuncias no dispara automáticamente la EIPD por su mera existencia, pero suele encajar en varios criterios que empujan hacia la exigibilidad (datos sensibles, evaluación sistemática, categorías especiales potenciales). Para una correduría que arranca canal, mi criterio operativo es hacerla en fase de implantación: no convertiría la ausencia de EIPD en un problema retroactivo, pero tampoco arrancaría un canal serio sin ella.
¿Hace falta una "cadena de hashes"?
Puede ser una buena medida de integridad. Pero no es una exigencia textual de la Ley 2/2023.
La Ley exige libro-registro, confidencialidad y garantías de protección; la AIPI ha comenzado a publicar recomendaciones técnicas más detalladas y actualizó varias en julio de 2026. Esas recomendaciones, no obstante, explican expresamente que carecen de carácter normativo vinculante.
Por eso tampoco escribiría "un Excel no vale".
Un Excel sin control de accesos, sin trazabilidad y editable por media empresa será difícil de defender como sistema adecuado. Pero jurídicamente el problema está en las garantías que ofrece, no en la extensión .xlsx.
La comprobación práctica que haría
Una vez al trimestre revisaría:
- usuarios que mantienen permisos sobre el canal;
- expedientes con más de tres meses y razón de su conservación;
- accesos realizados;
- terceros que procesan datos;
- transferencias internacionales o subencargados;
- funcionamiento real de la anonimización y purga.
La Ley 2/2023 y el RGPD no compiten aquí. El RGPD define buena parte de las condiciones bajo las que el canal puede tratar información personal.
Y en un sistema en el que una filtración de identidad puede provocar represalias, esa relación entre ambas normas deja de ser teoría bastante rápido.