Retos de ciberseguridad 2026-2027 para empresas: dispersión de herramientas, normativa e IA en la sombra

Un cortafuegos de un fabricante, el EDR de otro, el correo filtrado por un tercero, un SIEM que recibe datos de todos ellos y un escáner de vulnerabilidades que solo se abre antes de la auditoría. Cada pieza llegó por un motivo justificado, ya fuera un incidente, una renovación o una exigencia normativa. Sumadas, dan decenas de consolas, alertas que nunca se correlacionan y un equipo que dedica más horas a mantener herramientas que a detectar ataques.

Los retos de ciberseguridad de 2026 y 2027 agravan esa tendencia, porque cada nueva vulnerabilidad, norma o uso de la IA suele resolverse con otra herramienta o con otro proveedor. Los datos internacionales permiten medir por qué crece la dispersión, cuánto cuesta, qué papel juegan la normativa, el hardware y la IA, y en qué casos un proveedor externo de ciberseguridad ayuda a reducirla y en cuáles la empeora.

¿Qué retos de ciberseguridad marcan 2026 y 2027 para las empresas?

Los retos de ciberseguridad para 2026 y 2027 son la explotación de vulnerabilidades, la dependencia de terceros, la IA en la sombra, la presión normativa y la falta de personal. Según el Data Breach Investigations Report 2026 de Verizon, con más de 22.000 brechas confirmadas en 145 países, la explotación de vulnerabilidades ya es la primera vía de entrada conocida.

• La explotación de vulnerabilidades está en el 31 % de las brechas como vector inicial, frente al 20 % del informe anterior. Solo el 26 % de las vulnerabilidades críticas del catálogo KEV de CISA se corrigió por completo, con una mediana de 43 días.
• Hay terceros implicados en el 48 % de las brechas, un 60 % más que el año anterior.
• El 45 % de los empleados ya usa IA con regularidad en el trabajo, y el 67 % de quienes acceden a ella desde equipos corporativos lo hace con cuentas no corporativas.
• DORA y las leyes que transponen NIS2 fijan plazos de horas para notificar incidentes graves o significativos. El ENS, y PCI DSS por vía contractual, piden además vigilancia continua y pruebas periódicas.
• Falta personal. En el estudio de ISC2 de 2025, con más de 16.000 profesionales, el 59 % declara carencias de competencias críticas o significativas, frente al 44 % del año anterior.

En España, INCIBE gestionó 122.223 incidentes en 2025, un 26 % más que en 2024, y detectó 237.028 sistemas vulnerables relevantes.

¿Qué es la dispersión de herramientas de seguridad?

La dispersión de herramientas de seguridad (tool sprawl en inglés) es la acumulación de productos de protección, detección y cumplimiento que se solapan y no comparten datos. Cada uno exige una consola, una licencia y un especialista. Crece por adición: cada riesgo nuevo o cada requisito suma un producto, y casi ninguno se retira.

Con los años, la organización paga funciones duplicadas, deja huecos sin cubrir y depende de personas que conocen herramientas que nadie más sabe manejar. El gasto acompaña a la tendencia. En julio de 2025, Gartner previó que el gasto mundial en seguridad de la información alcanzaría unos 240.000 millones de dólares en 2026, un 12,5 % más que en 2025.

¿Cuántas herramientas de seguridad usa una empresa?

Una gran empresa usa de media entre 45 y 83 herramientas de seguridad, según el estudio que se consulte. En marzo de 2025, Gartner cifró en 45 la media en una encuesta a 162 grandes empresas y recordó que el mercado tiene más de 3.000 proveedores.

El IBM Institute for Business Value y Palo Alto Networks llegaron a 83 soluciones de 29 proveedores distintos tras encuestar a 1.000 directivos de 21 sectores y 18 países. El 52 % señaló la complejidad como el mayor obstáculo para sus operaciones de ciberseguridad. Palo Alto Networks vende plataformas integradas, un interés comercial que hay que tener presente al leer la cifra.

El Cybersecurity Readiness Index 2025 de Cisco, con 8.000 responsables de 30 mercados, añade el efecto operativo. Más del 77 % afirma que sus infraestructuras, con más de diez soluciones puntuales, les impiden responder con rapidez. Solo el 4 % alcanza el nivel más alto de madurez del índice.

¿Por qué cuesta tanto integrar herramientas de seguridad?

Integrar herramientas de seguridad resulta difícil porque cada producto resuelve bien su parte y los fallos aparecen en las uniones entre ellos.

• Cada producto tiene su consola, su modelo de alertas y su lenguaje de consulta, y un analista que investiga un incidente salta entre cinco o seis pantallas para reconstruirlo.
• Un cortafuegos, un EDR y un servicio en la nube describen el mismo usuario, la misma IP o el mismo proceso con campos y nombres distintos; sin normalizar, el SIEM guarda datos que no correlaciona. Además, cada SIEM usa su modelo de datos (CIM en Splunk, ASIM en Sentinel, UDM en Google Security Operations, ECS en Elastic), y cambiar de SIEM obliga a rehacer analizadores y reglas.
• Los conectores y las API cambian con cada versión, y una integración puede dejar de enviar eventos sin que nadie lo note hasta que faltan en una investigación.
• Cada contrato vence en una fecha y se mide de forma distinta (por usuario, por equipo, por gigabyte ingerido), lo que complica retirar productos y calcular el coste total.
• Cuando se va la persona que configuró una herramienta, esta sigue funcionando, pero nadie sabe explicar por qué genera las alertas que genera.

La encuesta SOC 2025 de SANS, con participantes de 57 países, muestra el resultado. El 42 % de los SOC envía todos los datos al SIEM sin un plan para gestionarlos ni recuperarlos. Su autor advierte a los directivos de que, si no van a dedicar los recursos necesarios para que una herramienta funcione, es mejor no desplegarla.

¿Cómo influye la falta de personal?

La falta de personal multiplica el problema, porque cada herramienta añadida necesita a alguien que la entienda. Según ISC2, el 88 % de los profesionales encuestados asegura haber sufrido al menos un evento de ciberseguridad significativo por la escasez de competencias. Además, ISC2 ha dejado de estimar la brecha mundial de profesionales y pasó a medir carencias de competencias.

Cisco apunta en la misma línea: el 86 % de las organizaciones considera la escasez de especialistas un problema serio, y más de la mitad tiene más de diez puestos de ciberseguridad sin cubrir. En la encuesta de SANS, el 62 % de los profesionales de SOC cree que su organización no hace lo suficiente para retener talento, uno de los motivos por los que muchas empresas recurren a un SOC gestionado.

¿Cómo empuja la normativa a sumar herramientas?

La normativa empuja a sumar herramientas porque obliga a vigilar de forma continua, notificar incidentes en horas, probar las defensas con regularidad y demostrarlo todo con evidencias. NIS2, DORA, el ENS, PCI DSS e ISO 27001 lo piden con redacciones distintas, y cada obligación suele cubrirse con un producto, un servicio o un informe nuevo.

Ninguna de estas normas obliga a comprar un producto determinado. El riesgo aparece cuando cada requisito se cubre por separado: un SIEM para el ENS, otro proveedor para el pentest de PCI DSS, una plataforma de cumplimiento para ISO 27001 y el registro de información de DORA en una hoja de cálculo. Una organización sujeta a varias normas acaba manteniendo evidencias duplicadas, y el mismo control se audita varias veces con herramientas distintas.

La dirección tampoco puede delegar el asunto. El artículo 20 de NIS2 obliga a los Estados miembros a exigir que la dirección de las entidades sujetas apruebe las medidas de ciberseguridad, supervise su aplicación, responda por su incumplimiento y reciba formación. En el sector financiero, el artículo 5.2 de DORA ya atribuye esa responsabilidad al órgano de dirección. La comparativa entre ENS, ISO 27001, NIS2 y DORA ayuda a identificar los controles comunes que pueden cubrirse una sola vez.

¿En qué punto está NIS2 en España?

NIS2 sigue sin transponerse en España a 4 de noviembre de 2026. El Consejo de Ministros aprobó el 14 de enero de 2025 el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, y la ley no se ha publicado en el BOE. Sigue vigente el Real Decreto-ley 12/2018, que transpuso la primera directiva NIS y mantiene la obligación de notificar incidentes para los operadores que regula. El 8 de julio de 2026, la Comisión Europea llevó a Irlanda, España, Francia y Países Bajos ante el Tribunal de Justicia de la UE por no haber transpuesto la directiva, y pidió multas para los cuatro.

Esperar a la ley no reduce la carga. Las entidades financieras aplican DORA desde el 17 de enero de 2025. El sector público y las empresas que le prestan servicios en los sistemas afectados aplican el ENS, y quien almacena, procesa o transmite datos de tarjetas debe cumplir PCI DSS por contrato con las marcas y su banco adquirente. Preparar la adecuación a NIS2 sobre esa base evita montar otra capa de herramientas cuando llegue la ley.

¿Por qué la IA en la sombra es un reto de gobernanza?

La IA en la sombra es un reto de gobernanza porque las herramientas y agentes no aprobados se extienden más rápido que su control, y cada solución puntual añade otra capa de dispersión. Incluye herramientas y agentes de IA que la empresa no ha aprobado ni controla. También abarca automatizaciones sin código (Power Automate, Zapier o n8n), tokens de API personales y servidores MCP conectados al correo, al CRM o a los repositorios con permisos amplios y sin responsable.

Los datos muestran que el control va por detrás del uso. En el Work Trend Index 2024 de Microsoft y LinkedIn, con 31.000 personas de 31 países, el 75 % de los trabajadores del conocimiento ya usaba IA, y el 78 % de ellos llevaba al trabajo herramientas elegidas por su cuenta. El Cost of a Data Breach 2025 de IBM, basado en 600 organizaciones con brechas, cuantifica el efecto en las brechas.

• Una de cada cinco organizaciones sufrió una brecha relacionada con IA en la sombra, y las que tenían un uso elevado de ella pagaron de media 670.000 dólares más por brecha.
• El 97 % de las organizaciones con incidentes en modelos o aplicaciones de IA no tenía controles de acceso para la IA.
• El 63 % de las organizaciones con brechas no tenía una política de gobernanza de IA o aún la estaba elaborando, y de las que sí la tenían, solo el 34 % auditaba con regularidad el uso no autorizado.

Gartner prevé que en 2030 más del 40 % de las empresas sufra incidentes de seguridad o cumplimiento ligados a IA en la sombra. En su encuesta a 302 responsables de ciberseguridad, el 69 % sospechaba o tenía pruebas de que sus empleados usaban IA generativa pública prohibida.

¿Cuánto control necesita la IA sin frenar al negocio?

La IA necesita el control justo para saber qué se usa y qué datos salen, con una vía aprobada que resulte más rápida que la no autorizada. Los dos extremos tienen coste. Un control laxo expone datos de clientes, código o contratos en servicios que la empresa no gestiona y, si hay datos personales, sin contrato de encargo (art. 28 del RGPD) ni base para la transferencia internacional. Una prohibición total resta productividad frente a competidores que sí aprovechan la IA y, como sugiere el 67 % de accesos con cuentas no corporativas del DBIR, desplaza el uso a cuentas personales que nadie supervisa.

Un comité de IA con negocio, protección de datos, asesoría jurídica y seguridad fija estos límites y resuelve en un plazo acordado las solicitudes de herramientas nuevas:

• Un registro de usos de IA, aprobados o no, con responsable, finalidad y datos tratados, que se revisa cada trimestre con los registros del proxy o del CASB.
• Una clasificación sencilla de los datos que pueden salir, los que solo pueden usarse en herramientas aprobadas y los que no pueden salir nunca.
• Tres niveles de herramientas (aprobadas, permitidas solo con datos públicos y prohibidas), con cuentas corporativas, inicio de sesión único y un contrato que excluya entrenar modelos con los datos de la empresa. Las aprobadas deben cubrir los usos más demandados para que la alternativa permitida sea también la más cómoda.
• DLP sobre las instrucciones y los archivos enviados a la IA, con avisos por defecto y bloqueo solo para los datos que no pueden salir nunca.
• Agentes, automatizaciones sin código y servidores MCP inscritos en el registro, con permisos mínimos, tokens con caducidad, conexiones OAuth autorizadas por un administrador y un responsable de negocio. Las acciones que modifican datos o envían información fuera requieren aprobación humana y quedan registradas, como recomienda OWASP.
• Formación documentada sobre los usos permitidos y los riesgos de cada nivel, que acredita las medidas de alfabetización del artículo 4 del Reglamento de IA, exigibles desde el 2 de febrero de 2025. Desde el 27 de julio de 2026, el Reglamento (UE) 2026/1744 mantiene ese deber sin fijar un nivel determinado por persona.

ISO/IEC 42001 ofrece un sistema de gestión para ordenar todo lo anterior, y la adecuación al Reglamento de IA aclara qué usos de la empresa están prohibidos o son de alto riesgo. Los agentes con acceso a sistemas internos merecen una auditoría de seguridad específica. Las herramientas de seguridad para IA de la tabla siguiente tienen más sentido después de ese inventario.

¿Qué herramientas y equipos forman una pila de seguridad típica?

Una pila de seguridad típica combina hardware de perímetro, software de detección y servicios en la nube repartidos en una docena de capas. La tabla recoge las más habituales y algunos fabricantes de referencia en cada una.

Cortafuegos, concentradores VPN y equipos de acceso remoto se gestionan como dispositivos con su firmware, su ciclo de vida y sus contratos de soporte, y a menudo conviven modelos de varios fabricantes por fusiones, sedes o proyectos antiguos. La gestión de hardware y software forma parte de la seguridad tanto como la detección.

En planta cambian las reglas. Muchos autómatas y equipos con sistemas operativos antiguos no admiten agente EDR ni parches frecuentes, y una contención automática puede parar una línea. La detección se apoya en monitorización pasiva de red y en segmentación por zonas y conductos, como propone la serie ISA/IEC 62443. El contrato con el SOC debe excluir acciones automáticas sobre OT sin aprobación de planta.

¿Puede una herramienta de seguridad convertirse en la puerta de entrada?

Una herramienta de seguridad puede convertirse en la puerta de entrada, porque también es software expuesto que hay que parchear. En el DBIR 2025, los dispositivos de perímetro y las VPN pasaron del 3 % al 22 % de las acciones de explotación de vulnerabilidades, con una mediana de 32 días para corregirlas por completo.

Entre 2024 y 2025 se explotaron vulnerabilidades en equipos de perímetro de Ivanti, Fortinet, Palo Alto Networks, Cisco, Citrix y SonicWall. En septiembre de 2025, CISA emitió una directiva de emergencia para los cortafuegos Cisco ASA y Firepower. Las agencias de los Five Eyes publicaron en febrero de 2025, junto a otros socios, una guía conjunta para proteger dispositivos de perímetro. En los parques FortiGate, Fortinet retiró el modo túnel de SSL VPN en FortiOS 7.6.3 y recomienda migrar a IPsec, una ocasión para revisar quién accede en remoto y desde qué equipos.

El riesgo alcanza también a las plataformas de detección. En 2026 se explotó una vulnerabilidad crítica en Splunk Enterprise, y el grupo TeamPCP comprometió escáneres de seguridad de código abierto para robar credenciales. Por eso cada herramienta de seguridad necesita un responsable y un lugar en el ciclo de parches, como el resto de sistemas.

¿Cuánto cuesta la dispersión?

La dispersión cuesta de media un 5 % de los ingresos anuales, según los directivos encuestados por IBM y Palo Alto Networks, además de tiempo de respuesta y atención del equipo. Según el mismo informe, las organizaciones con plataformas integradas tardan 72 días menos en identificar un incidente y 84 menos en contenerlo, con un retorno de la inversión casi cuatro veces mayor. Son cifras de un estudio en el que participa un fabricante de plataformas.

El coste más visible está en las alertas. Una encuesta de Vectra AI a 2.000 profesionales de seguridad, publicada en octubre de 2024, concluyó que los equipos solo pueden atender el 38 % de las alertas que reciben. El 60 % cree que los fabricantes venden herramientas que generan demasiado ruido.

A eso se suman las licencias sin uso, las horas de mantenimiento de integraciones y el coste de ingesta de un SIEM que almacena registros sin aprovecharlos. Decidir qué registros enviar al SIEM y cuánto tiempo conservarlos suele ser el primer ahorro. Las plataformas de canalización de datos, como Cribl o Logstash, filtran, normalizan y enrutan eventos antes del SIEM y envían los de poco valor a almacenamiento más barato, lo que abarata la ingesta, aunque añaden otra pieza que mantener.

¿Plataforma única o la mejor herramienta de cada categoría?

Ni la plataforma única ni la mejor herramienta por categoría funcionan como regla general. La plataforma reduce consolas, correlaciona de forma nativa y simplifica contratos. A cambio, ata a un proveedor, puede incluir módulos inferiores a la alternativa especializada y concentra el riesgo.

En muchas empresas, parte de la plataforma ya está pagada. Microsoft 365 Business Premium incluye Defender for Business, Defender for Office 365 Plan 1, Entra ID P1, Intune y Purview, y Microsoft anunció que E3 incorpora funciones de Defender for Office 365 Plan 1 con la subida de precios de julio de 2026. El complemento Microsoft Defender Suite, antes E5 Security, añade Defender for Endpoint Plan 2, Defender for Identity, Defender for Cloud Apps y Entra ID P2. Revisar esas licencias es la primera palanca para retirar productos solapados, aunque la comparación debe incluir horas de operación y asumir más dependencia de un fabricante.

El 19 de julio de 2024, una actualización defectuosa de CrowdStrike dejó fuera de servicio unos 8,5 millones de equipos Windows, según Microsoft. No fue un ataque. Un archivo de contenido (Channel File 291) provocó una lectura de memoria fuera de límites en el controlador de núcleo del sensor Falcon, y ese riesgo de concentración afecta tanto a una plataforma como a un producto especializado instalado en todos los equipos.

Muchas organizaciones combinan pocas plataformas con una capa de datos abierta. Tres estándares reducen la dependencia de un fabricante:

• OCSF, un esquema común para registros y alertas impulsado por AWS, Cisco, IBM y Splunk, que entró en la Linux Foundation en noviembre de 2024 con unas 200 organizaciones participantes.
• Sigma, un formato de reglas de detección que se convierte a las consultas de Splunk, Microsoft Sentinel, Elastic o QRadar, entre otros.
• STIX y TAXII, los estándares de OASIS para describir e intercambiar inteligencia de amenazas.

Gartner aporta tres avisos de su encuesta de 2022, cuando el 75 % de las organizaciones buscaba reducir su número de proveedores, frente al 29 % de 2020. El ahorro no debe ser el motivo principal, el proceso exige al menos dos años y la concentración del mercado no termina nunca.

¿Hacia dónde va la concentración del mercado?

El mercado se concentra en pocos grandes grupos, y una herramienta elegida hoy por ser independiente puede pertenecer mañana a un competidor, con cambios de hoja de ruta, precios o soporte.

Entre 2024 y 2026, Cisco cerró la compra de Splunk, Palo Alto Networks se quedó con los activos SaaS de IBM QRadar y con CyberArk, y Google completó la compra de Wiz por 32.000 millones de dólares.

Los servicios gestionados siguen el mismo camino: Sophos compró Secureworks en febrero de 2025 y LevelBlue integró Trustwave en agosto de 2025. Antes de firmar un contrato largo hay que preguntar qué ocurre con los datos y las reglas si el producto cambia de dueño.

¿Cómo se reduce la dispersión de herramientas de seguridad?

La consolidación de herramientas de ciberseguridad funciona por fases que siguen el calendario de renovaciones, desde el inventario y el mapa de cobertura hasta la medición del resultado, sin sustituciones masivas.

1. Inventario de herramientas, licencias, fechas de renovación, responsables, datos que generan y destino de esos datos.
2. Mapa de cobertura frente a MITRE ATT&CK y frente a los requisitos normativos, con un único catálogo de controles para todas las normas.
3. Revisión de solapamientos (dos productos para lo mismo) y de huecos (técnicas o requisitos sin cubrir).
4. Baja de las licencias sin uso y reducción de productos al vencer cada contrato, empezando por las capas con más solapamiento y tras una ejecución en paralelo que confirme que se mantienen las fuentes y las detecciones.
5. Una capa de datos común que fije qué registros se recogen, en qué formato y durante cuánto tiempo.
6. Evidencias unificadas, de modo que un mismo control sirva a NIS2, DORA, ENS, PCI DSS e ISO 27001.
7. Medición antes y después: tiempo medio de detección y de respuesta, porcentaje de alertas revisadas, número de consolas y coste por activo protegido.
8. Un plan de salida documentado para cada servicio TIC que sustente funciones esenciales o importantes, como exige a las entidades financieras el artículo 28.8 de DORA.

Un CISO virtual puede dirigir este proceso cuando la empresa no tiene un responsable de seguridad a tiempo completo.

¿Cuándo tiene sentido un proveedor externo de ciberseguridad?

Un proveedor externo tiene sentido cuando la empresa no puede sostener por sí sola la integración, la vigilancia 24x7 y la actualización de las detecciones. Un MSSP o un servicio de SOC gestionado con MDR bien elegido cubre esas carencias en estos puntos:

• Integraciones, conectores y normalización de datos que el proveedor mantiene para muchos clientes y que la empresa no tiene que rehacer en cada actualización.
• Analistas que trabajan a diario con las herramientas del mercado, en turnos que cubren noches y festivos.
• Reglas de detección y procedimientos de respuesta actualizados con lo que se observa en otros clientes y fuentes de inteligencia.
• Apoyo para notificar incidentes en los plazos de NIS2 y DORA, e informes que sirven como evidencia en auditorías.
• Una opinión externa sobre qué herramientas conservar, cuáles retirar y cómo conectar el pentest y la gestión de vulnerabilidades con la detección, más fiable si el proveedor declara sus acuerdos de reventa con fabricantes.

La comparativa entre EDR, XDR y MDR y la de SOC interno frente a SOC gestionado ayudan a decidir qué funciones externalizar. En una empresa mediana, el reparto habitual deja dentro la gestión del riesgo, la prioridad de los activos, la autorización de contenciones, la titularidad de licencias y datos y el gobierno de proveedores. Fuera suelen ir la vigilancia 24x7, la ingeniería de detección, el pentest y un servicio de respuesta a incidentes con forense contratado de antemano.

¿Hasta dónde llega la responsabilidad del proveedor?

La responsabilidad del proveedor llega hasta lo que firma el contrato; la de cumplir la norma sigue siendo de la empresa. DORA lo dice de forma expresa en su artículo 28.1.a): la entidad financiera sigue siendo «plenamente responsable» aunque externalice servicios TIC. NIS2 incluye la seguridad de la cadena de suministro entre las medidas obligatorias (artículo 21.2.d), de modo que el proveedor de seguridad es también un tercero que hay que evaluar.

NIS2 incluye además a los proveedores de servicios de seguridad gestionados en el sector «Gestión de servicios de TIC (de empresa a empresa)» de su anexo I. Los medianos y grandes quedan sujetos a la directiva a través de la ley nacional (art. 2.1), y el Reglamento de Ejecución (UE) 2024/2690 fija sus medidas técnicas.

Un proveedor externo también puede añadir dispersión si trae su SIEM, su portal y su sistema de incidencias sin retirar los de la empresa.

Un SOC externo tampoco conoce el negocio, y sin una persona interna que priorice activos y autorice contenciones, el servicio se limita a reenviar avisos. Hay que aclarar desde el principio a quién pertenecen los datos, las reglas de detección y el histórico de casos, y cómo se recuperan al terminar. Para funciones esenciales o importantes, DORA exige además derechos de acceso, inspección y auditoría y un período de transición en caso de salida (artículo 30.3). La gestión del riesgo de terceros debe incluir al proveedor de seguridad como a uno más.

¿Con qué preguntas se evalúa a un MSSP o un MDR?

Un MSSP o un MDR se evalúa con preguntas que obliguen a fijar por escrito lo que la oferta comercial deja abierto:

• ¿Trabaja con las herramientas que la empresa ya tiene o exige sustituirlas por las suyas?
• ¿A quién pertenecen los datos, las reglas y los casos cuando termina el contrato, y en qué formato se entregan?
• ¿Qué tiempos de triaje y contención se comprometen, con qué penalizaciones, y qué acciones de contención puede ejecutar sin aprobación previa?
• ¿Las licencias del SIEM y del EDR están a nombre de la empresa o del proveedor, y admite un modelo cogestionado con acceso interno a reglas y datos?
• ¿Cómo apoya la notificación inicial en 4 horas de DORA o la alerta temprana en 24 horas de NIS2?
• ¿Qué parte del servicio está subcontratada y a qué empresas?
• ¿Acepta auditorías del servicio y pruebas de su plan de salida?
• ¿Cómo demuestra cada trimestre, con ejercicios de purple team o simulación de ataques sobre MITRE ATT&CK, que la cobertura mejora y que el número de herramientas no crece?
• ¿Cómo detecta y avisa cuando una fuente de registros deja de enviar eventos?
• ¿Recoge el informe mensual los tiempos por severidad, el porcentaje de alertas escaladas que resultan incidentes y las reglas añadidas o retiradas?
• ¿Qué fuentes de datos incluye el precio y cómo se factura el crecimiento del volumen de ingesta?

¿Por dónde empezar?

El primer paso es un inventario honesto de herramientas, licencias, renovaciones y responsables, cruzado con las normas que aplican a la empresa. En una empresa de 500 a 1.000 empleados, el recorrido suele durar entre 12 y 18 meses.

• En el primer trimestre, inventario, MFA en todos los accesos, parcheo del perímetro, copias inmutables con restauración probada y decisión sobre las licencias de Microsoft.
• Entre los meses 4 y 9, vigilancia 24x7 sobre las herramientas existentes y retirada de duplicados al vencer cada contrato.
• Entre los meses 10 y 18, segmentación y monitorización de planta, evidencias comunes para ENS y NIS2 y un ejercicio de crisis con la dirección.

El presupuesto se compara mejor como coste anual por empleado, sumando licencias, servicio externo y horas internas. La política de IA puede redactarse en paralelo, con datos de lo que la plantilla ya usa.

Si se externaliza sin ese inventario, la dispersión suele trasladarse al proveedor. Con el inventario hecho, el contrato puede fijar objetivos medibles, como el número de consolas, el porcentaje de alertas revisadas y las evidencias normativas reutilizadas.