Brechas de datos personales y RGPD en Málaga

¿Qué es una brecha de datos personales?

Una brecha de datos personales es una violación de seguridad que provoca la destrucción, pérdida o alteración accidental o ilícita de datos personales, o bien su comunicación o acceso no autorizado. Es la definición del artículo 4.12 del Reglamento General de Protección de Datos. Afecta tanto a ficheros digitales como a documentación física y no exige que exista una intrusión deliberada.

Puede producirse en una pequeña tienda que envía una factura al destinatario equivocado, en una clínica que pierde un expediente, en una asesoría con acceso indebido a nóminas o en una empresa que sufre un ataque de ransomware. Lo relevante es qué ha ocurrido con la información personal y qué consecuencias puede tener para las personas afectadas.

El análisis debe partir de los hechos, no de la etiqueta utilizada por el proveedor tecnológico. Un incidente puede calificarse inicialmente como posible brecha y confirmarse después de investigar; conviene conservar el momento en que se identificó y las evidencias que justifican esa decisión.

Incidente informático, ciberataque y brecha: tres conceptos diferentes

Un incidente de seguridad es un suceso que afecta o puede afectar a la seguridad de un sistema o proceso. Un ciberataque es una actuación maliciosa sobre sistemas, redes o cuentas. Una brecha de datos personales existe cuando se comprometen datos personales en los términos del RGPD. Los tres conceptos pueden coincidir, pero no son equivalentes.

• Un intento de phishing bloqueado antes de acceder a ninguna cuenta puede ser un incidente sin brecha.
• Enviar un correo con datos de clientes a otra persona puede constituir una brecha sin que exista ataque alguno.
• Un ransomware puede comprometer disponibilidad, confidencialidad o ambas, según los hechos y las evidencias.

Si necesitas analizar ataques, malware y defensa técnica de redes, consulta nuestra página de ciberataques y RGPD. Esta página se centra en la respuesta jurídica y organizativa cuando se ven afectados datos personales.

Los tres tipos de brecha: confidencialidad, integridad y disponibilidad

Confidencialidad: datos que llegan a personas no autorizadas, por ejemplo al compartir una carpeta de clientes públicamente o al enviar por error un informe médico a otro destinatario. El riesgo puede incluir fraude, suplantación de identidad, discriminación o exposición de información íntima.

Integridad: datos alterados indebidamente, como cambiar por accidente una cuenta bancaria, modificar un historial o manipular registros que después se utilizan para tomar decisiones sobre personas. El perjuicio no siempre depende de que se haya divulgado información.

Disponibilidad: datos personales perdidos, destruidos o inaccesibles cuando deben utilizarse, por ejemplo porque fallan las copias de seguridad o porque un cifrado malicioso impide acceder a historiales de pacientes. Recuperar la información con rapidez puede reducir el impacto, pero no borra automáticamente la necesidad de documentar el suceso.

Una misma brecha puede reunir las tres características. Por ello, el informe no debe limitarse a preguntar si «han robado datos».

Correo enviado a la persona equivocada: un caso muy habitual

Una empresa adjunta por error a una respuesta comercial un documento con datos de otro cliente. Incluso si el error se advierte de inmediato, es preciso determinar qué datos se enviaron, a quién, cuántas personas se ven afectadas y qué posibilidad real existe de utilización indebida.

Entre las primeras medidas pueden estar solicitar al receptor que elimine el mensaje y confirme que no lo ha redistribuido, bloquear enlaces compartidos y evitar nuevos envíos. Esa confirmación ayuda a valorar el riesgo, pero no garantiza por sí sola que la información no se haya leído o copiado.

No es lo mismo divulgar una cita comercial sin información sensible que remitir un listado con DNI, datos bancarios o tratamientos médicos. El número de afectados es relevante, pero también la naturaleza y el contexto. En nuestro blog explicamos un caso de correo enviado a un destinatario equivocado y cómo iniciar la evaluación.

Ransomware: no asumir que hubo robo, ni descartarlo sin investigar

Cuando un ransomware cifra los servidores, la organización puede perder temporalmente el acceso a datos personales. Se trata de un posible problema de disponibilidad incluso si después consigue restaurar los equipos. Si existen indicios de extracción, acceso externo o publicación de bases de datos, hay que analizar también la confidencialidad.

La ausencia de una publicación pública no demuestra por sí sola que no haya fuga. A la inversa, tampoco es correcto afirmar automáticamente que todo ataque de ransomware implica una filtración de información. El equipo técnico debe revisar registros, movimientos de cuentas, accesos remotos, conexiones de salida y alcance del cifrado, dejando constancia de las limitaciones de la investigación.

Mientras se analiza, conviene mantener los sistemas afectados aislados cuando proceda, asegurar las copias limpias y preservar evidencias antes de efectuar operaciones que puedan borrar rastros. El asesoramiento de protección de datos y la respuesta técnica deben coordinarse desde el inicio.

Carpetas compartidas, enlaces públicos y errores de configuración en la nube

Un enlace de almacenamiento abierto a «cualquiera con el enlace», una base de datos sin autenticación o una cuenta de un extrabajador todavía activa pueden exponer información sin que aparezca ninguna alerta de antivirus. En estos casos conviene averiguar desde cuándo estaba accesible, qué datos contenía y qué registros de acceso existen.

Como primera respuesta se pueden revocar permisos, cerrar el enlace, invalidar sesiones y revisar los usuarios autorizados. Pero cambiar los permisos no sustituye a la investigación: es necesario valorar si la información fue efectivamente accesible, si hay evidencias de descarga y qué riesgos persisten.

En Microsoft 365, Google Workspace, gestores documentales y aplicaciones SaaS, las opciones de auditoría dependen del plan y de la configuración. Una buena gestión de permisos y medidas de seguridad reduce la exposición y facilita demostrar qué ocurrió.

Portátiles, móviles, USB y documentos extraviados

La pérdida de un portátil con datos de clientes, una memoria USB con nóminas o una carpeta de expedientes en transporte puede constituir una brecha. La evaluación cambia si el dispositivo estaba protegido por cifrado robusto, credenciales adecuadas y mecanismos que hagan ininteligibles los datos a terceros.

La simple existencia de una contraseña de Windows no equivale necesariamente a cifrado del disco. Hay que verificar las medidas concretas, su estado en el momento del incidente y si existían copias accesibles de los datos. En dispositivos gestionados pueden ayudar el bloqueo remoto, la revocación de sesiones o la retirada de certificados, siempre documentando las actuaciones.

También deben revisarse las pérdidas en papel: informes médicos olvidados, documentación de trabajadores en un contenedor o expedientes entregados a la dirección equivocada. El soporte físico no excluye la aplicación del RGPD.

Errores humanos, empleados y accesos internos indebidos

Una brecha puede deberse a una cuenta compartida, un trabajador que consulta expedientes fuera de sus funciones o una persona que copia información antes de dejar la empresa. No basta con que el acceso se haya realizado desde una cuenta corporativa: importa si existía autorización y necesidad para acceder a esos datos.

Ante indicios de uso indebido deben revisarse perfiles y registros, limitar los accesos que supongan riesgo y asegurar las evidencias. En paralelo, las actuaciones sobre trabajadores deben respetar las garantías laborales, el principio de proporcionalidad y las políticas de uso previamente comunicadas.

La formación debe permitir que el personal comunique errores rápidamente, incluso cuando se hayan cometido de buena fe. Retrasar la comunicación por miedo a una sanción interna puede aumentar el daño y dificultar la notificación dentro de plazo.

Qué hacer en las primeras horas: contener, preservar y coordinar

La prioridad inmediata es frenar la exposición y proteger a las personas. Según el incidente puede ser necesario revocar contraseñas, desactivar cuentas, retirar un archivo público, aislar equipos, recuperar una copia válida o contactar con un destinatario accidental. No conviene esperar a tener un informe definitivo para iniciar estas medidas.

Al mismo tiempo deben preservarse las pruebas: mensajes originales, capturas, registros de autenticación, comunicaciones con proveedores, horas de detección y cambios realizados. Un borrado indiscriminado o una reinstalación precipitada pueden hacer imposible conocer el alcance real.

• Asignar un responsable de coordinación y activar soporte técnico, RGPD y dirección.
• Abrir un registro del incidente con fechas, sistemas y personas implicadas.
• Identificar a los proveedores que deban colaborar y establecer un canal seguro.
• Valorar cuanto antes si se confirma la afectación de datos personales.

La investigación técnica, la continuidad del negocio y las obligaciones de notificación deben avanzar coordinadas, no una después de otra.

Cronología del incidente: por qué importan las horas y las evidencias

Es habitual que una empresa conozca primero un síntoma —un correo raro, un equipo bloqueado— y más tarde confirme que se ha producido una brecha. La cronología debe distinguir la hora del incidente, la de detección, la de confirmación de la brecha y la de cada acción de respuesta.

Hay que conservar las comunicaciones internas y de proveedores, las decisiones tomadas y los motivos. Si una notificación se realiza fuera de plazo, la organización deberá poder explicar la dilación. Si se concluye que no era necesario notificar, también necesitará evidencias de la valoración realizada.

Los datos aún desconocidos deben registrarse como pendientes, evitando completar el expediente con suposiciones. Una investigación puede ir incorporando nueva información, y esa evolución debe quedar visible. El objetivo del registro no es buscar culpables, sino poder responder, corregir y demostrar diligencia.

¿Cuándo empiezan las 72 horas del RGPD?

El artículo 33 establece que, cuando deba notificarse a la autoridad de control, debe hacerse sin dilación indebida y, de ser posible, a más tardar en 72 horas desde que el responsable tenga constancia de la brecha. No se cuentan desde que termina la investigación forense ni desde que se reúne el comité de dirección.

El momento de constancia se relaciona con disponer de un grado razonable de certeza de que ha ocurrido un incidente que afecta a datos personales. Una sospecha inicial exige investigar con diligencia; confirmada la brecha, no debe posponerse la evaluación de riesgos para agotar el plazo.

Las horas incluyen fines de semana y festivos. Si se supera el plazo, la notificación debe acompañarse de los motivos de la demora. La AEPD explica el procedimiento y las condiciones de notificación.

Cómo valorar el riesgo para los derechos y libertades de las personas

La decisión central no depende solo de si el negocio va a perder dinero o reputación. El RGPD exige valorar el perjuicio potencial para las personas físicas afectadas: fraude, suplantación, discriminación, perjuicios económicos, exposición de información confidencial, pérdida de control sobre sus datos o interrupción de servicios esenciales.

Entre los factores están el tipo y volumen de datos, facilidad de identificación, número de personas, vulnerabilidad de los afectados, probabilidad de acceso no autorizado y capacidad de mitigar los daños. Una sola historia clínica puede generar un riesgo importante; miles de identificadores que no permiten identificar a personas en un contexto concreto pueden ofrecer un escenario diferente.

La valoración debe estar razonada y vinculada a las pruebas disponibles. Si hay incertidumbre relevante, hay que explicitarla y revisar la conclusión a medida que aparecen nuevos hechos, especialmente cuando se trata de categorías especiales de datos o de posibles fraudes.

Tres escenarios prácticos: documentar, notificar o comunicar

1. Riesgo improbable para las personas: por regla general no existe obligación de notificar a la autoridad de control, pero sí de documentar la brecha. Ejemplo orientativo: pérdida de un dispositivo con cifrado robusto y medidas verificadas que hacen ininteligible la información.

2. Riesgo probable: se activa la obligación de notificar a la autoridad de control competente conforme al artículo 33. Por ejemplo, una exposición de datos identificativos y financieros con posibilidad razonable de uso indebido.

3. Alto riesgo probable: además de la notificación a la autoridad, como regla general procede comunicar la brecha a los afectados sin dilación indebida, salvo que concurra alguna excepción legal del artículo 34. Ejemplo orientativo: publicación no autorizada de datos especialmente sensibles con riesgos graves y directos.

Son ejemplos, no umbrales automáticos. La valoración real depende de las circunstancias y de las medidas de protección disponibles.

Cuándo y cómo notificar una brecha a la AEPD

Las empresas privadas sujetas a la competencia de la AEPD deben utilizar el canal específico de notificación de brechas de su sede electrónica cuando la brecha pueda entrañar un riesgo para los derechos y libertades. No equivale a presentar una denuncia, reclamar contra un tercero o enviar un correo genérico a la Agencia.

La notificación no supone por sí misma que se vaya a imponer una sanción ni que se abra necesariamente un procedimiento. Demostrar que se actuó con diligencia, que se valoró el riesgo y que se adoptaron medidas forma parte de la responsabilidad proactiva.

En casos complejos, puede notificarse con la información inicial disponible y completarse por fases sin retrasos indebidos. Para entidades públicas pueden existir autoridades autonómicas competentes; conviene determinar la autoridad de control antes de enviar datos sobre el incidente.

Consulta el apartado oficial de notificación de la AEPD y sus enlaces a la sede.

Qué información debe incluir la notificación

El artículo 33.3 indica que, como mínimo, se debe describir la naturaleza de la brecha, las categorías y el número aproximado de interesados y registros afectados cuando sea posible, el nombre y datos de contacto del DPD o punto de contacto, las consecuencias probables y las medidas adoptadas o propuestas para remediarla y mitigar sus efectos.

La organización debe separar lo confirmado de lo estimado: «aproximadamente 300 clientes» es una estimación distinta de «300 clientes confirmados». También conviene explicar si la investigación sigue abierta y qué información se aportará después. La comunicación con la autoridad puede ampliarse en fases cuando no sea posible recopilar todos los datos a la vez.

Preparar con antelación un formulario interno, un listado de responsables y una plantilla de cronología ayuda a no perder tiempo en el momento de la brecha. La información remitida debe ser coherente con el registro interno del incidente.

Cuándo hay que comunicar la brecha a las personas afectadas

El artículo 34 exige comunicar la brecha a las personas afectadas cuando sea probable que implique un alto riesgo para sus derechos y libertades. Esta comunicación tiene una finalidad distinta a la notificación administrativa: permitir que cada persona tome medidas para protegerse, como cambiar credenciales, controlar movimientos bancarios o desconfiar de mensajes fraudulentos.

Debe realizarse sin dilación indebida; no existe un plazo genérico adicional de 72 horas para avisar a los afectados. El aviso se redacta en lenguaje claro, explica qué ocurrió, las consecuencias posibles y las medidas de mitigación, e incluye un punto de contacto.

Cuando sea viable, debe dirigirse a quienes realmente están expuestos al alto riesgo. Un aviso impreciso que omite lo esencial o llega a un público equivocado puede resultar ineficaz. La AEPD ofrece criterios para comunicar brechas a los afectados.

Excepciones a la comunicación a afectados: cuándo pueden aplicarse

El artículo 34.3 prevé supuestos en los que no es necesaria la comunicación individual, aunque haya existido una brecha, como cuando las medidas de protección apropiadas hacían ininteligibles los datos para terceros no autorizados —por ejemplo, un cifrado eficaz—, o cuando medidas posteriores garantizan que el alto riesgo ya no es probable.

También se contempla el esfuerzo desproporcionado; en ese caso puede ser necesaria una comunicación pública o una medida similar igualmente eficaz. No es una excepción para evitar informar por incomodidad o coste sin analizar los hechos.

Estas condiciones no eliminan la necesidad de documentar la brecha y justificar la decisión. Tampoco deben confundirse con el criterio del artículo 33 para decidir si procede notificar a la autoridad, que utiliza el umbral de riesgo probable y no el de alto riesgo.

¿Y si la investigación no ha terminado al llegar al plazo?

Es frecuente que una brecha afecte a múltiples servidores, cuentas o proveedores y que su alcance completo no pueda cerrarse en tres días. El RGPD permite que la información requerida se facilite por fases cuando no sea posible comunicarla de una vez. Esto no justifica guardar silencio hasta disponer de todos los detalles.

Si existe obligación de notificar, la empresa debería remitir la información que conoce, identificar las incertidumbres y actualizar el expediente cuando aparezcan nuevos hechos. Si se notifica después de las 72 horas, debe explicar las razones de la demora.

Una comunicación inicial no sustituye la investigación ni las medidas de contención. El expediente debe reflejar las correcciones efectuadas, el análisis del riesgo en cada fase y las decisiones de informar o no a las personas afectadas. En casos de especial impacto, la AEPD recomienda no demorar los contactos pertinentes.

El registro de brechas: obligatorio incluso cuando no se notifica

El artículo 33.5 obliga al responsable a documentar todas las brechas de datos personales, incluidas las no notificables. El registro debe recoger los hechos, sus efectos y las medidas correctivas adoptadas para que la autoridad competente pueda verificar el cumplimiento.

Un registro útil identifica fecha, responsable, sistemas, categorías de datos, personas potencialmente afectadas, causa, evidencia disponible, acciones de contención, valoración del riesgo, decisión sobre notificación, comunicación a afectados, responsables de seguimiento y fecha de cierre.

No basta con guardar un correo que diga «incidencia solucionada». Si se decide no notificar, es especialmente importante dejar constancia de las razones: cifrado verificado, acceso descartado con evidencias, medidas efectivas o riesgo improbable según circunstancias. El principio de responsabilidad proactiva

Responsable y encargado del tratamiento: quién debe avisar

La empresa u organización que determina las finalidades y medios esenciales del tratamiento suele actuar como responsable y conserva la obligación de valorar el riesgo y, en su caso, notificar a la autoridad o comunicar a afectados. Un proveedor que trata datos personales por su cuenta puede actuar como encargado y debe informar al responsable sin dilación indebida cuando conoce una brecha.

No existe en el RGPD un plazo único de 72 horas para que el encargado avise al responsable: lo exigido es rapidez, sin dilación indebida, y pueden existir compromisos contractuales más estrictos. Un proveedor no debería esperar a terminar su investigación para advertir de un problema relevante.

Los contratos deben incluir canales de emergencia, contactos operativos, información mínima que proporcionará el proveedor, conservación de evidencias y cooperación. Si un encargado notifica en nombre del responsable por acuerdo, ello no extingue automáticamente las responsabilidades de este último.

Qué hacer si el incidente ocurre en el hosting, CRM o proveedor cloud

Una incidencia en el hosting, el CRM, un servicio de copias de seguridad o una plataforma de reservas puede afectar a varios clientes empresariales a la vez. Cada organización debe identificar qué información personal suya estaba implicada y su rol real frente al servicio.

Es importante solicitar al proveedor una cronología clara, alcance, categorías de datos, registros de acceso, medidas adoptadas, estado de restauración y canales de actualización. Una nota de prensa genérica del proveedor no reemplaza la valoración específica de los tratamientos afectados.

También hay que determinar si existen subencargados y flujos internacionales relevantes. Para preparar estos escenarios conviene revisar los Registros de Actividades de Tratamiento y los contratos de proveedores, evitando asumir que todo servicio tecnológico tiene automáticamente el mismo rol jurídico.

Ejemplos de brechas en comercios, asesorías, clínicas y academias

Comercio electrónico: exportación accidental de pedidos con nombre, dirección y teléfono; hay que averiguar a quién se entregó, alcance y medidas correctivas. Asesoría: carpeta de nóminas compartida con un cliente distinto; se evalúa la confidencialidad, tipos de datos y personas afectadas.

Clínica o centro sanitario: extravío de un expediente o acceso no autorizado a una ficha médica; el posible daño a la intimidad suele exigir un análisis especialmente cuidadoso. Academia: publicación por error de una lista de alumnos con datos identificativos; además del contexto, importa la edad y situación de los afectados.

Empresa de mantenimiento: robo de portátil con contactos de clientes, contraseñas o accesos remotos; el alcance puede extenderse a sistemas ajenos. Centro de estética: exposición de una ficha de contraindicaciones o alergias; algunas respuestas pueden revelar datos de salud.

Estos supuestos son orientativos: no convierten en obligatoria la notificación por el mero nombre del sector. La decisión exige valorar el caso real.

Datos de salud, menores, biometría y otros colectivos vulnerables

El impacto potencial de una brecha depende también de la sensibilidad y el contexto. Pueden necesitar especial atención los datos de salud, información sobre menores, víctimas de violencia, datos financieros, localización detallada, credenciales de acceso, información íntima o datos utilizados para adoptar decisiones que afecten significativamente a una persona.

No todo dato especialmente protegido produce automáticamente un resultado idéntico, pero las consecuencias pueden ser más graves aunque el número de registros sea pequeño. Una única ficha de salud expuesta a una persona del entorno social del afectado puede ocasionar perjuicios significativos.

La organización debe estudiar si las personas pueden sufrir discriminación, acoso, extorsión, fraude, daños reputacionales o una pérdida relevante de control sobre su información. La capacidad de los afectados para adoptar medidas protectoras también es importante: un menor o una persona dependiente puede necesitar un tratamiento especialmente cuidadoso de la comunicación.

Medidas técnicas que reducen la probabilidad y el impacto de una brecha

Las obligaciones de respuesta no sustituyen a la prevención. El artículo 32 del RGPD exige medidas técnicas y organizativas adecuadas al riesgo. En la práctica pueden incluir autenticación multifactor, permisos mínimos, cifrado de equipos, control de sesiones, actualización de software, detección de actividad sospechosa y protección del correo electrónico.

También importan los registros de eventos y su conservación: sin ellos puede resultar imposible saber quién descargó un archivo o cuándo se produjo un acceso. La seguridad de las cuentas administrativas, el inventario de activos y la gestión de bajas de empleados son fundamentales.

Las medidas deben estar documentadas, implantadas y verificadas; una política que no se aplica tiene poco valor durante un incidente. Nuestro servicio de medidas técnicas y organizativas RGPD profundiza en la adaptación de controles a cada actividad.

Copias de seguridad, restauración y pérdida de disponibilidad

Una copia de seguridad no es útil si no puede recuperarse. Para reducir el impacto de la pérdida de disponibilidad es recomendable definir qué datos son críticos, la frecuencia de copia, las ubicaciones protegidas, los permisos de acceso y el tiempo objetivo de recuperación.

Las pruebas de restauración deben formar parte del procedimiento habitual. Guardar la única copia conectada permanentemente al mismo equipo puede permitir que una infección afecte a originales y respaldos. Según el entorno, pueden ser apropiadas copias aisladas, controles de inmutabilidad y cifrado.

Cuando se produce una brecha de disponibilidad, hay que valorar si la interrupción puede perjudicar a las personas: un retraso en una campaña comercial no tiene las mismas consecuencias que la imposibilidad de acceder a información necesaria para atender a pacientes. La restauración puede disminuir el riesgo, pero no elimina el deber de registrar la brecha.

Protocolo interno de brechas: quién hace qué y a quién llama

El peor momento para buscar contraseñas, contratos o números de contacto es durante una crisis. Cada organización debería tener un procedimiento proporcionado a su tamaño que indique a quién avisar, cómo abrir un registro, quién decide las medidas técnicas urgentes y quién realiza la evaluación RGPD.

En una pyme, las funciones pueden concentrarse en pocas personas, pero deben estar asignadas. Si existe DPD, debe integrarse en el circuito de asesoramiento sin convertirle por defecto en el único responsable de las decisiones. La dirección y el responsable del tratamiento mantienen sus obligaciones.

Conviene prever situaciones fuera del horario laboral, fines de semana y ausencia de la persona habitual de contacto. Un procedimiento breve y probado suele ser más útil que un documento extenso que nadie conoce. La formación del personal debe incluir cuándo reportar y qué no hacer para no destruir pruebas.

Simulacros y revisión posterior: convertir el incidente en una mejora

Una vez contenida la brecha, toca revisar su causa, los fallos de detección, los tiempos de respuesta y los controles que han de cambiar. No basta con cambiar una contraseña si el origen fue una cuenta compartida, permisos mal asignados o una ausencia de revisión de accesos.

Pequeños ejercicios ayudan a comprobar si la plantilla sabe comunicar un envío erróneo, si el proveedor responde fuera de horario, si es posible restaurar los datos y si la dirección puede tomar decisiones con información incompleta. Deben probarse tanto incidentes técnicos como errores humanos.

El seguimiento debe tener responsables y fechas: quién revisará permisos, actualizará cláusulas contractuales, implantará MFA, corregirá la configuración cloud o reforzará el procedimiento. La auditoría y revisión del cumplimiento puede ayudar a verificar que esas mejoras se sostienen en el tiempo.

¿Puede haber otras obligaciones además de las del RGPD?

La notificación de los artículos 33 y 34 no es necesariamente la única obligación asociada a un incidente. Dependiendo de la actividad y del marco aplicable, una organización puede tener que atender exigencias contractuales, normas sectoriales, obligaciones de ciberseguridad, comunicación a aseguradoras o colaboración con autoridades competentes.

Estas obligaciones no sustituyen ni deben confundirse con el procedimiento de protección de datos. Por ejemplo, comunicar un incidente técnico al proveedor o pedir asistencia a INCIBE no equivale a presentar la notificación de brecha personal cuando sea obligatoria.

Antes de actuar conviene identificar el sector, la naturaleza del servicio, los contratos y la autoridad competente, sin asumir que todas las pymes se encuentran sometidas a los mismos requisitos adicionales. Para la mayoría de empresas, el punto de partida seguirá siendo confirmar la brecha, evaluar los riesgos personales y documentar la respuesta.

Herramientas oficiales: Asesora Brecha y Comunica-Brecha RGPD

La Agencia Española de Protección de Datos dispone de recursos gratuitos para orientar la toma de decisiones. Asesora Brecha ayuda a valorar la posible obligación de notificar a la autoridad de control. Comunica-Brecha RGPD facilita el análisis de la posible comunicación a los interesados.

Estas herramientas no sustituyen la decisión del responsable ni representan una autorización de la AEPD para un caso concreto. Su resultado debe interpretarse con las características del tratamiento, los datos afectados, el contexto y las evidencias de la investigación.

También resulta útil consultar la guía oficial de gestión de brechas y el propio texto del RGPD. Es conveniente conservar la fecha de consulta y documentar cómo se integró el resultado de la herramienta en la evaluación del incidente.

Cómo te ayudamos a gestionar y prevenir brechas de datos en Málaga

En RGPD Málaga podemos ayudar a las empresas a organizar la evaluación de la brecha, documentar las decisiones y preparar las actuaciones de protección de datos, coordinándonos con los responsables del negocio, proveedores tecnológicos y, cuando corresponda, el Delegado de Protección de Datos.

El trabajo incluye delimitar el incidente, identificar los tratamientos y las personas potencialmente afectadas, apoyar la valoración del riesgo, preparar registros y comunicaciones cuando procedan, y proponer medidas correctivas. Si el incidente tiene componente técnico, coordinamos la revisión de accesos, registros, equipos y copias de seguridad con los profesionales correspondientes.

También podemos revisar el procedimiento preventivo: canales de aviso, obligaciones con proveedores, formación, permisos y documentación. No prometemos que toda brecha sea inocua ni una garantía de ausencia de sanciones; el objetivo es una respuesta rápida, proporcionada, justificable y centrada en las personas.

Si acaba de producirse un incidente, contacta con RGPD Málaga cuanto antes e indica cuándo se detectó, qué sistemas o documentos están afectados y qué medidas se han tomado. No envíes datos sensibles o contraseñas en un primer mensaje abierto.