Este informe analiza las debilidades técnicas, factores culturales, problemas legales y comparaciones internacionales que explican por qué las filtraciones continúan ocurriendo.

1. Principales incidentes recientes

Estos casos muestran que las filtraciones no son incidentes aislados, sino síntomas de problemas sistémicos.

2. Debilidades técnicas y organizativas comunes

2‑1. Gestión insuficiente de privilegios (Access Control)

• Permisos excesivos para empleados y contratistas
• Auditorías de acceso poco frecuentes
• Aplicación inconsistente de MFA

2‑2. Cifrado insuficiente y errores en la configuración de la nube

• Datos sensibles almacenados sin cifrado
• Buckets mal configurados accesibles desde el exterior

2‑3. Falta de monitoreo continuo

• Auditorías anuales o trimestrales
• Ausencia de detección en tiempo real
• Filtraciones que permanecen meses sin ser detectadas

2‑4. Dependencia excesiva de subcontratistas

• Cadena de proveedores compleja
• Responsabilidad difusa
• Respuesta lenta ante incidentes

3. Factores culturales en las empresas japonesas

3‑1. Aversion al riesgo y retraso en la divulgación

Las empresas tienden a evitar daños reputacionales, lo que provoca demoras en la comunicación de incidentes.

3‑2. Cultura de cumplimiento en lugar de cultura de seguridad

Muchas compañías se enfocan en “cumplir con APPI” en vez de adoptar medidas de seguridad proactivas.

3‑3. Estructuras jerárquicas rígidas

Los ingenieros de seguridad tienen poca autonomía, y las decisiones críticas requieren múltiples aprobaciones.

4. Limitaciones del marco legal japonés

4‑1. Diferencias entre APPI y GDPR

• APPI enfatiza consentimiento y notificación
• GDPR impone sanciones severas y reportes obligatorios

4‑2. Sanciones débiles

La mayoría de los incidentes terminan con “orientación administrativa”, sin multas significativas.

4‑3. Regulación fragmentada

Cada sector está supervisado por un ministerio distinto, lo que dificulta la estandarización.

5. Comparación internacional: Japón frente a otros mercados

Japón queda rezagado en transparencia y sanciones, lo que reduce los incentivos para mejorar la seguridad.

6. Conexión entre Times Car y el incidente del GSS

Aunque uno es un organismo gubernamental y el otro una empresa privada, ambos incidentes comparten patrones:

• Dependencia de contratistas
• IAM débil
• Errores de configuración
• Divulgación tardía
• Gobernanza fragmentada

Esto demuestra que los problemas son nacionales, no sectoriales.

7. Recomendaciones para fortalecer la seguridad corporativa en Japón

Las empresas deben:

• Adoptar arquitecturas Zero Trust
• Fortalecer IAM y MFA
• Implementar monitoreo continuo
• Establecer políticas claras de divulgación
• Integrar la ciberseguridad en la gobernanza corporativa

Conclusión

Las filtraciones de datos en Japón no son simples fallos técnicos, sino el resultado de factores culturales, organizativos, tecnológicos y legales. Sin reformas estructurales, los incidentes seguirán ocurriendo y afectarán la confianza en el ecosistema digital japonés.

Este informe analiza las debilidades del sistema My Number y las compara con los principales sistemas de identidad digital del mundo.

1. Debilidades estructurales del sistema My Number

1‑1. Arquitectura de datos fragmentada y sin gestión centralizada

A diferencia de sistemas como eID de Estonia o Aadhaar de India, My Number no utiliza una base de datos centralizada.

Los datos están distribuidos entre:

• Ministerios y agencias gubernamentales
• Gobiernos locales
• Empresas privadas (bancos, aseguradoras, telecomunicaciones, alquiler de vehículos, etc.)

Esto provoca:

• Estándares de seguridad inconsistentes
• Errores de vinculación entre sistemas
• Dificultad para detectar anomalías de forma transversal

Los incidentes de vinculación incorrecta en seguros médicos y pensiones (2023–2024) son una consecuencia directa de esta estructura fragmentada.

1‑2. Dependencia de procesos manuales y documentos físicos

Muchos procedimientos relacionados con My Number aún requieren:

• Entrada manual de datos
• Verificación humana
• Documentos en papel

Esto genera:

• Errores de entrada
• Vinculaciones incorrectas
• Riesgos humanos de seguridad
• Baja eficiencia administrativa

Los sistemas avanzados ya operan con verificación automatizada y autenticación cifrada.

1‑3. Gestión débil de identidad y acceso (IAM)

My Number involucra a:

• Organismos gubernamentales
• Gobiernos locales
• Empresas privadas
• Contratistas
• Integradores de sistemas

Los métodos de autenticación y gestión de permisos varían ampliamente entre instituciones.

Riesgos:

• Permisos excesivos
• Aplicación inconsistente de MFA
• Supervisión insuficiente de conexiones externas
• Falta de detección de anomalías en tiempo real

El incidente del sistema GSS (246,000 registros potencialmente filtrados) es un ejemplo claro de estas debilidades.

1‑4. Baja transparencia y retrasos en la divulgación de incidentes

Japón suele:

• Publicar incidentes con retraso
• Proporcionar pocos detalles técnicos
• Emitir informes posteriores limitados
• Compartir escasas lecciones entre organismos

Esto afecta la confianza pública y dificulta la mejora del sistema.

2. Por qué My Number es propenso a errores de configuración y filtraciones

2‑1. Integración compleja con empresas privadas

My Number se utiliza en:

• Apertura de cuentas bancarias
• Servicios de seguros
• Alquiler de vehículos (Times Car)
• Reservas de viaje (SkyTicket)
• Servicios de telecomunicaciones

Cada empresa tiene estándares de seguridad distintos, lo que genera riesgos desiguales en el ecosistema.

El incidente de Times Car (6.6 millones de registros filtrados) demuestra cómo las debilidades del sector privado afectan al sistema My Number.

2‑2. Cadena de subcontratación extensa y responsabilidad difusa

Los sistemas suelen involucrar:

• Contratistas principales
• Subcontratistas de segundo nivel
• Subcontratistas de tercer nivel

Esto provoca:

• Mayor riesgo de errores de configuración
• Corrección lenta de vulnerabilidades
• Ambigüedad en la responsabilidad

El incidente del GSS ocurrió porque una cuenta de mantenimiento externa fue explotada.

2‑3. Falta de adopción completa del modelo Zero Trust

Japón aún depende de defensas perimetrales tradicionales. Los sistemas modernos utilizan:

• Autenticación continua
• Monitoreo en tiempo real
• IAM centralizado
• Verificación cifrada

La coexistencia de sistemas antiguos y nuevos dificulta la adopción de Zero Trust.

3. Comparación internacional: cómo se posiciona Japón frente a otros sistemas de identidad

3‑1. Estonia eID: el modelo más avanzado del mundo

• Arquitectura centralizada
• Integridad garantizada por blockchain
• Autenticación cifrada obligatoria
• Monitoreo continuo
• Alta transparencia

Casi no existen errores de vinculación.

3‑2. India Aadhaar: enorme escala con autenticación fuerte

• Cobertura de 1.3 mil millones de personas
• Autenticación biométrica (huellas, iris)
• Base de datos centralizada
• Gobernanza estricta de API
• Divulgación rápida de incidentes

Aunque ha tenido filtraciones, su estructura facilita la respuesta.

3‑3. Estados Unidos SSN: alto riesgo por uso extendido en el sector privado

• No existe un sistema digital centralizado
• SSN se usa ampliamente en servicios privados
• Alto riesgo de robo de identidad
• Sin autenticación cifrada

My Number comparte algunos riesgos con SSN en su integración con empresas privadas.

3‑4. Japón My Number: sistema híbrido, fragmentado y complejo

• No centralizado
• Gestión distribuida
• Mezcla de sistemas antiguos y nuevos
• Alto riesgo de errores de configuración
• Adopción lenta de Zero Trust

En conjunto, Japón enfrenta riesgos mayores que otros países avanzados.

4. Riesgos futuros revelados por incidentes recientes

4‑1. Errores de vinculación muestran problemas de integridad de datos

Los incidentes en seguros médicos, pensiones y registros municipales no son casos aislados, sino síntomas estructurales.

4‑2. El incidente GSS revela debilidades en IAM gubernamental

• Cuenta externa explotada
• Vulnerabilidad en VPN
• 246,000 registros potencialmente filtrados

Indica fallas graves en la infraestructura digital del gobierno.

4‑3. El incidente de Times Car muestra riesgos del sector privado

• 6.6 millones de registros filtrados
• Imágenes de licencias comprometidas
• Gobernanza API insuficiente
• Estándares de seguridad inconsistentes

El ecosistema My Number depende de sistemas privados con seguridad desigual.

Conclusión

El sistema My Number enfrenta riesgos estructurales profundos:

• Arquitectura fragmentada
• IAM débil
• Procesos manuales
• Cadena de subcontratación compleja
• Baja transparencia
• Sistemas antiguos que dificultan la modernización

Los incidentes recientes (GSS, Times Car, errores de vinculación) son manifestaciones claras de estos problemas.

Este informe analiza las causas organizativas, técnicas y culturales que explican por qué los incidentes de seguridad y los errores operativos continúan ocurriendo.

1. Dependencia excesiva de contratistas externos

El gobierno japonés depende en gran medida de:

• Grandes proveedores de TI
• Subcontratación en múltiples niveles
• Personal externo de mantenimiento

Esto genera riesgos claros:

● Responsabilidad fragmentada

Varios proveedores gestionan partes del sistema, lo que significa que nadie es responsable del conjunto.

● Gestión débil de privilegios

Las cuentas de mantenimiento suelen tener permisos excesivos. El incidente de GSS es un ejemplo directo.

● Lentitud en la corrección de vulnerabilidades

La coordinación entre múltiples proveedores retrasa actualizaciones y parches.

2. Infraestructura antigua y modernización lenta

Muchos sistemas gubernamentales aún dependen de:

• Dispositivos VPN obsoletos
• Servidores locales (on‑premise)
• Métodos tradicionales de autenticación
• Marcos tecnológicos sin funciones modernas de seguridad

Esto provoca:

• Exposición a vulnerabilidades conocidas
• Dificultad para integrar herramientas de monitoreo
• Complejidad operativa y mantenimiento costoso

En contraste, países como Estonia y Singapur ya operan con arquitecturas cloud‑native.

3. Gobernanza de seguridad fragmentada

Aunque la Agencia Digital supervisa la estrategia nacional, cada ministerio gestiona sus propios sistemas y reglas de seguridad.

Esto genera:

● Estándares inconsistentes

Algunos ministerios adoptan modelos de confianza cero, otros siguen usando defensas perimetrales tradicionales.

● Falta de monitoreo transversal

Las amenazas que afectan a varios sistemas son difíciles de detectar.

● Cadena de reporte lenta

Las alertas de seguridad deben pasar por múltiples niveles jerárquicos.

4. Factores culturales y organizativos

La cultura administrativa japonesa influye directamente en el DX:

● Aversion al riesgo

Las instituciones evitan cambios drásticos, lo que perpetúa el uso de sistemas antiguos.

● Persistencia de procesos en papel

Incluso en 2026, muchos trámites siguen dependiendo de documentos físicos.

● Estructura organizativa altamente segmentada

Los ministerios operan de forma independiente, dificultando la estandarización.

5. Debilidades en la gestión de identidad y acceso (IAM)

El incidente de GSS reveló fallas críticas:

• Permisos excesivos en cuentas externas
• Aplicación inconsistente de MFA
• Supervisión insuficiente de conexiones externas
• Ausencia de detección de anomalías en tiempo real

Los gobiernos digitales avanzados (Estonia, India, EAU) ya utilizan IAM centralizado y monitoreo continuo.

6. Ecosistema de proveedores demasiado complejo

Los sistemas gubernamentales suelen involucrar:

• Contratistas principales
• Subcontratistas de segundo nivel
• Subcontratistas de tercer nivel
• Personal independiente de mantenimiento

Esto provoca:

• Ambigüedad en la responsabilidad
• Errores de configuración
• Lentitud en la corrección de fallos
• Políticas de seguridad difíciles de unificar

El incidente de GSS es una manifestación directa de este problema.

7. Falta de transparencia y retrasos en la divulgación

Comparado con estándares internacionales:

• Japón publica incidentes con retraso
• Proporciona pocos detalles técnicos
• Los informes posteriores son limitados
• Las lecciones no se comparten entre ministerios

Países como Reino Unido, EE.UU. y Estonia publican informes completos, lo que mejora la madurez de la ciberseguridad nacional.

Conclusión

La digitalización del gobierno japonés enfrenta desafíos estructurales profundos:

• Dependencia excesiva de contratistas
• Infraestructura antigua
• Gobernanza fragmentada
• Cultura administrativa conservadora
• IAM débil
• Ecosistema de proveedores complejo
• Transparencia insuficiente

El incidente de GSS no es un caso aislado, sino un síntoma de problemas sistémicos que requieren reformas urgentes.

Resumen del incidente

La Agencia Digital de Japón confirmó que su plataforma Government Solution Service (GSS) fue objeto de un acceso no autorizado desde el exterior. El ataque aprovechó una vulnerabilidad en un dispositivo VPN, lo que permitió que un tercero accediera a archivos que contenían información personal de empleados gubernamentales.

Aunque los datos de ciudadanos comunes no se vieron afectados, el incidente se considera uno de los más graves dentro del proceso de digitalización del gobierno japonés.

1. Cronología del incidente

25 de junio de 2024

Se detecta que una cuenta de mantenimiento accedió de forma anómala a una gran cantidad de archivos.

9 de julio de 2024

La investigación revela que un tercero explotó una vulnerabilidad en un dispositivo VPN para infiltrarse en el sistema. Ese mismo día, la cuenta afectada fue suspendida y se bloquearon las comunicaciones externas.

Julio 2024 – 2026

Con la colaboración de expertos externos, se confirma que parte de la información personal pudo haber sido obtenida por el atacante.

2. Datos potencialmente filtrados (aprox. 246,000 registros)

Personas afectadas

• Empleados de ministerios y agencias gubernamentales
• Funcionarios públicos
• Contratistas
• Personas relacionadas con actividades administrativas ※ No incluye datos de ciudadanos comunes

Tipos de información comprometida

(con duplicados incluidos)

• Nombres: aprox. 236,000
• Direcciones de correo electrónico: aprox. 231,000
• Números de teléfono: aprox. 94,000
• Direcciones físicas: aprox. 10,000
• Otra información relacionada con actividades administrativas

Distribución interna

• Información de empleados gubernamentales: aprox. 189,000
• Información de contratistas y particulares: aprox. 57,000

3. Situación confirmada hasta el momento

• No se ha detectado uso indebido posterior
• Existe riesgo de phishing y suplantación de identidad
• La Agencia Digital está notificando individualmente a los afectados
• No se filtraron contraseñas ni información financiera

4. Causas y problemas estructurales

Causas técnicas

• Vulnerabilidad explotada en un dispositivo VPN
• Uso indebido de una cuenta de mantenimiento
• Supervisión insuficiente de conexiones externas

Problemas estructurales

• Gestión débil de la información dentro de organismos administrativos
• Exceso de privilegios otorgados a contratistas
• Auditorías de seguridad insuficientes
• Cuestionamientos sobre la seguridad de la infraestructura digital del gobierno

5. Respuesta de la Agencia Digital

• Notificación individual a los afectados
• Advertencias sobre correos y mensajes sospechosos
• Investigación continua con expertos externos
• Revisión del proceso de gestión de vulnerabilidades
• Mejora de los métodos de conexión externa
• Refuerzo de medidas de prevención de incidentes futuros

Conclusión

Este incidente revela fallas profundas en la infraestructura de seguridad digital del gobierno japonés. Aunque los datos de ciudadanos no se vieron comprometidos, la posible filtración de 246,000 registros de empleados y contratistas afecta gravemente la confianza en el sistema administrativo. El caso también ha generado preocupación internacional sobre la seguridad digital del gobierno japonés.

A principios de octubre de 2026, más de 30,000 personas ya se han registrado para participar, una cifra que ha crecido de manera explosiva en pocos días y que refleja la gravedad del caso.

■ 1. Número actual de participantes en la demanda colectiva

● Más de 30,000 usuarios registrados

Según los datos confirmados el 4 de octubre de 2026:

• Entre los usuarios afectados por la filtración,
• más de 30,000 ya se han inscrito para unirse a la demanda colectiva

El aumento fue tan rápido que pasó de “unos pocos miles” a “decenas de miles” en cuestión de días.

■ 2. ¿Por qué creció tan rápido el número de participantes?

● ① La cantidad de usuarios afectados es enorme

El incidente comprometió 6.6 millones de cuentas, incluyendo 1.6 millones con imágenes de licencias de conducir, información extremadamente sensible.

● ② Difusión masiva en redes sociales

Las publicaciones del abogado que lidera la demanda superaron los 3 millones de visualizaciones, lo que aceleró la inscripción de nuevos participantes.

● ③ Preocupación por el robo de identidad

Los usuarios temen:

• Uso indebido de datos personales
• Aumento de correos de phishing
• Accesos no autorizados a cuentas

Esto ha impulsado la búsqueda de protección legal.

■ 3. Objetivos de la demanda colectiva

La demanda busca:

• Investigar la negligencia de Times Car en la gestión de seguridad
• Obtener compensación para los afectados
• Exigir estándares más estrictos de protección de datos
• Clarificar la responsabilidad de los sistemas tercerizados

No es solo una acción contra una empresa, sino un movimiento que podría transformar la seguridad digital en Japón.

■ 4. Estado actual del proceso legal

● ① Fase de “preparación”

El equipo legal está:

• Recolectando información de los afectados
• Preparando documentos legales
• Solicitando explicaciones oficiales a Times Car
• Analizando posibles modelos de compensación

● ② Puntos clave del litigio

El caso probablemente se centrará en:

• Configuración de seguridad insuficiente
• Falta de gestión de permisos
• Monitoreo ineficaz de accesos anómalos
• Auditorías deficientes en sistemas tercerizados

■ 5. ¿Qué significa esto para los usuarios?

Si la demanda tiene éxito, los afectados podrían recibir:

• Compensación económica
• Servicios de protección de identidad
• Asistencia legal
• Mejores estándares de seguridad en el futuro

Esto podría convertirse en un precedente importante en la protección de datos en Japón.

【Conclusión】

La filtración de datos de Times Car ya es uno de los incidentes de privacidad más graves en Japón. Más de 30,000 usuarios se han unido a la demanda colectiva, y la cifra continúa aumentando.

Esta acción legal no solo busca justicia para los afectados, sino que también podría impulsar reformas profundas en la seguridad del sector de movilidad compartida.

■ 1. Impacto para los usuarios

Aunque Times Car no ha confirmado la filtración de información financiera, los usuarios enfrentan varios riesgos importantes.

● ① Aumento de correos de phishing y estafas

Los atacantes pueden usar datos filtrados (nombre, correo, teléfono) para enviar mensajes falsos como:

• “Su reserva ha sido cancelada, confirme aquí.”
• “Actividad sospechosa detectada en su cuenta.”

Este tipo de ingeniería social es común tras incidentes de seguridad.

● ② Intentos de acceso no autorizado

Si un usuario utiliza la misma contraseña en múltiples servicios, los atacantes pueden realizar ataques de relleno de credenciales (credential stuffing).

● ③ Estrés y preocupación por la privacidad

Incluso si los datos filtrados no son extremadamente sensibles, saber que terceros poseen información personal genera ansiedad y pérdida de confianza.

■ 2. Impacto para la empresa

El incidente también afecta directamente a Times Car en varios niveles.

● ① Pérdida de confianza en la marca

Los servicios de movilidad compartida dependen de la confianza del usuario. Una filtración puede provocar que los clientes migren a competidores.

● ② Presión legal y regulatoria

La Ley de Protección de Información Personal de Japón exige reportes y explicaciones detalladas. Si se demuestra negligencia, Times Car podría enfrentar sanciones.

● ③ Incremento de costos operativos

Tras un incidente, la empresa debe invertir en:

• Auditorías de seguridad
• Consultoría externa
• Reparación de sistemas
• Atención al cliente
• Posibles compensaciones

Esto genera una carga financiera significativa.

■ 3. Impacto para el sector de movilidad compartida

El caso de Times Car revela problemas estructurales en todo el sector.

● ① Riesgo elevado por la centralización de datos

Las plataformas de autos compartidos almacenan grandes volúmenes de información. Una sola brecha puede afectar a miles de usuarios.

● ② Auditorías insuficientes en sistemas tercerizados

Muchas empresas dependen de desarrolladores externos, pero no aplican estándares de seguridad uniformes.

● ③ Infraestructura híbrida con sistemas antiguos

El uso simultáneo de sistemas viejos y nuevos crea puntos débiles que los atacantes pueden explotar.

■ 4. Medidas de protección para los usuarios

Para reducir riesgos, los usuarios deben tomar acciones inmediatas:

● ① Cambiar la contraseña de Times Car

Evitar usar la misma contraseña en otros servicios.

● ② Desconfiar de correos sospechosos

No abrir enlaces desconocidos ni proporcionar información personal.

● ③ Activar la autenticación en dos pasos (si está disponible)

Esto añade una capa adicional de seguridad.

● ④ Revisar periódicamente la actividad de la cuenta

Ante cualquier anomalía, contactar al soporte de Times Car.

■ 5. Medidas de protección para las empresas

Las empresas deben reforzar su seguridad para evitar incidentes similares.

● ① Implementar autenticación multifactor (MFA)

Reduce drásticamente el riesgo de accesos no autorizados.

● ② Adoptar un modelo de seguridad Zero Trust

Incluso dentro de la red interna, cada acceso debe ser verificado.

● ③ Realizar pruebas de penetración periódicas

Las auditorías externas ayudan a detectar vulnerabilidades ocultas.

● ④ Fortalecer la gestión de sistemas tercerizados

Todos los proveedores deben cumplir estándares de seguridad estrictos.

● ⑤ Aplicar el principio de minimización de datos

Guardar solo la información necesaria y eliminar datos antiguos.

【Conclusión】

El incidente de Times Car demuestra que la seguridad en la movilidad compartida es un desafío creciente. Los usuarios deben mantenerse alerta, y las empresas deben adoptar medidas de protección más estrictas. En la próxima parte analizaremos la responsabilidad empresarial y las tendencias futuras del sector.

En este artículo analizamos por qué ocurrió la filtración, cuáles fueron los fallos técnicos involucrados y qué debilidades internas hicieron posible el ataque.

【1. Resumen del incidente】

Times Car confirmó que información de algunos usuarios fue accedida de manera no autorizada. Los datos potencialmente expuestos incluyen:

• Nombre del usuario
• Dirección de correo electrónico
• Número de teléfono
• Número de membresía
• Historial de reservas

La empresa indicó que no se ha confirmado la filtración de datos de tarjetas de crédito, aunque la investigación continúa.

Este incidente demuestra que incluso grandes plataformas pueden ser vulnerables cuando existen brechas en su arquitectura de seguridad.

【2. ¿Por qué ocurrió? — Análisis técnico de las causas】

● ① Vulnerabilidades en sistemas expuestos al exterior

Los atacantes aprovecharon fallos en interfaces o módulos web que no estaban configurados correctamente. Este tipo de vulnerabilidad suele aparecer en:

• APIs sin restricciones adecuadas
• Servicios web desactualizados
• Módulos externos sin mantenimiento

● ② Gestión deficiente de permisos internos

Una vez dentro del sistema, los atacantes pudieron acceder a capas que no deberían estar disponibles. Esto indica que Times Car no aplicaba el principio de mínimo privilegio, una práctica esencial en seguridad moderna.

● ③ Falta de monitoreo y análisis de registros

El sistema no detectó de inmediato los accesos anómalos. La permanencia prolongada del atacante dentro del sistema aumentó el riesgo de filtración.

● ④ Integración problemática entre sistemas antiguos y nuevos

Times Car aún utiliza partes de su infraestructura antigua, conectadas a plataformas más recientes. Este tipo de “arquitectura híbrida” suele generar:

• Incompatibilidades
• Puntos débiles en interfaces
• Brechas de seguridad difíciles de detectar

【3. Debilidades estructurales dentro de la empresa】

El incidente no es un caso aislado; refleja problemas comunes en el sector de movilidad compartida en Japón.

Entre las debilidades más relevantes se encuentran:

• Auditorías insuficientes en sistemas desarrollados por terceros
• Falta de estándares unificados de cifrado
• Capacitación limitada en seguridad para empleados
• Ausencia de pruebas de penetración periódicas

Estas fallas crean un entorno donde un solo error puede desencadenar una filtración masiva.

【Conclusión】

La filtración de datos de Times Car no fue causada por un único fallo, sino por una combinación de vulnerabilidades técnicas y debilidades estructurales. El incidente demuestra que la seguridad en servicios de movilidad compartida debe ser tratada como un proceso continuo, no como una medida puntual.

En la siguiente parte analizaremos el impacto del incidente y las medidas de protección para usuarios y empresas.