--- title: "La adopción de la seguridad empieza en el consejo, no en el helpdesk | Guardian360" description: "La adopción real no es si los usuarios finales hacen clic en los botones correctos; es si los directivos responsables del ciberriesgo entienden el cuadro de mando." url: https://guardian360.net/es/blog/security-adoption-begins-in-the-boardroom/ locale: en source: guardian360.net --- [← Todas las publicaciones](https://guardian360.net/es/blog/) Partners # La adopción de la seguridad empieza en el consejo, no en el helpdesk Por Jan Martijn Broekhof · 18 de mayo de 2026 El sector de los MSP por fin ha empezado a hablar de adopción. Se habla de licencias de Copilot, puntuaciones de concienciación y estructuras de Teams, todo ello sobre los usuarios finales. La conversación más difícil, la que más importa, todavía no ha empezado de verdad: ¿entienden de verdad las personas personalmente responsables del ciberriesgo los cuadros de mando que su MSP les está mostrando? Esa pregunta volvió a surgir en varias conversaciones recientes con clientes, en distintas sesiones con partners y una vez más durante un episodio reciente de MSP Late Night, donde la adopción fue, por fin, el tema central. Las voces alrededor de la mesa fueron agudas sobre Copilot, sobre la formación en concienciación y sobre la brecha entre vender una licencia y cambiar el comportamiento. Pero la discusión se quedó casi por completo en el usuario final. En seguridad de la información y cumplimiento, donde NIS2 ha hecho ahora personalmente responsables a los directivos, el punto ciego más grande está un piso más arriba. ## La adopción no es solo un problema del usuario final Cuando los MSP hablan de adopción, suelen referirse a lo mismo que los proveedores de productividad. ¿Está la gente usando la herramienta? ¿Están dando instrucciones a Copilot? ¿Están completando el módulo de concienciación? ¿Están haciendo clic en los botones correctos del sistema correcto? Esas preguntas importan. Pero en seguridad y cumplimiento hay una segunda pregunta de adopción que casi nunca se plantea. ¿Entiende el directivo que firmó el contrato lo que la herramienta le está diciendo? ¿Lee el cuadro de mando el directivo que es personalmente responsable del resultado? ¿Dirige la organización el equipo directivo, dueño del riesgo de negocio, a partir de las cifras que produce? Si no lo hacen, el cuadro de mando no está adoptado. Está pagado. Eso es otra cosa. ## ¿Cómo sabe un directivo si su MSP le está protegiendo de verdad? Esta es la pregunta que dueños, directivos y miembros del consejo escriben en los buscadores y hacen a sus asesores de confianza. Es también la pregunta que los MSP están peor equipados para responder en un lenguaje apto para el consejo. El Global Cybersecurity Outlook 2026 del World Economic Forum, publicado en enero de 2026 con Accenture y basado en las respuestas de 804 altos directivos de 92 países, capta la brecha en dos cifras. Entre las organizaciones que el WEF clasifica como altamente resilientes, el noventa y nueve por ciento afirma que su consejo participa en la ciberseguridad. Alentador a primera vista. Sigue leyendo el mismo informe y solo el cincuenta y dos por ciento de esas mismas organizaciones dice que sus consejeros reciben de verdad actualizaciones periódicas de ciberseguridad. “La participación sin información no es lo mismo que la supervisión.” La misma encuesta es contundente sobre un segundo punto: lo que preocupa al CEO y lo que preocupa al CISO ya no coinciden. Los CEO ponen el fraude habilitado por medios digitales y el phishing en lo más alto de sus preocupaciones; los CISO siguen situando el ransomware en primer lugar. Miran el mismo panorama de amenazas y sacan conclusiones distintas, porque leen cuadros de mando distintos en vocabularios distintos. Para un directivo, la pregunta de “¿estoy protegido?” no puede responderse señalando un Secure Score, un porcentaje de cumplimiento o un mapa de calor codificado por colores. Solo puede responderla alguien dispuesto a traducir la puntuación en consecuencias para el negocio: ingresos en riesgo, contratos en riesgo, responsabilidad personal en riesgo. ## Un cuadro de mando no es una estrategia Entra en la organización media del mercado medio que usa un MSP para seguridad y cumplimiento, y encontrarás cuadros de mando. Microsoft Secure Score. Un recuento de vulnerabilidades de un escáner. Un porcentaje de preparación para ISO 27001. Una autoevaluación de NIS2. Una consola de Defender o EDR. A veces, una vista personalizada del propio MSP. Lo que normalmente no encontrarás es una respuesta breve a la pregunta: “¿Qué significa todo esto para nuestro negocio este trimestre?” La Defenders Survey 2025 de Trend Micro, que encuestó a más de tres mil profesionales de ciberseguridad, lo planteó con claridad. Solo alrededor del treinta por ciento de los encuestados dijo que su organización tiene “un modelo estructurado y continuo para comunicar sobre eventos de seguridad con las partes interesadas”. El informe concluía que gestionar el ciberriesgo a nivel directivo “requiere traducción: expresar los riesgos en términos de negocio en lugar de técnicos”. Los cuadros de mando existen, los datos existen, las herramientas funcionan. El cuello de botella es la capa de traducción. Y la capa de traducción es, casi por definición, el papel de quien se sitúa entre la tecnología y el consejo. Para la mayoría de las organizaciones del mercado medio, ese es el MSP. Hans ten Hove, habitual en la mesa de MSP Late Night, lo resumió sin rodeos en una publicación en neerlandés en LinkedIn: “una solución no adoptada, escribió, es simplemente una factura cara con un cuadro de mando adjunto”. Esa es la frase que conviene tener en mente cada vez que se despliega un nuevo cuadro de mando de cumplimiento. ## ¿Qué cambió NIS2 discretamente sobre la responsabilidad del consejo? La discusión sería teórica si no fuera por el giro legal que ya ha llegado con firmeza. Bajo el artículo 20 de la Directiva NIS2, el órgano de dirección de una entidad esencial o importante debe aprobar las medidas de gestión de riesgos de ciberseguridad de la organización, supervisar su implementación y seguir una formación obligatoria para poder evaluar los ciberriesgos. Como expuso DLA Piper en un análisis de la directiva de noviembre de 2025, esta responsabilidad no puede delegarse en el departamento de TI ni externalizarse a un proveedor externo. Los Estados miembros han recibido la potestad de imponer responsabilidad personal a los directivos individuales y, en casos graves, de suspender de sus funciones a un CEO o representante legal. La revisión de la BSI-Gesetz alemana, que entró en vigor el 6 de diciembre de 2025, va todavía más lejos. Hace a los órganos de dirección personalmente responsables de implementar realmente las medidas de ciberriesgo, no solo de aprobarlas. El regulador alemán ha confirmado que, una vez pasado el plazo de registro del 6 de marzo de 2026, ha entrado en una fase de aplicación activa. Para un MSP, la implicación es más aguda de lo que parece a primera vista. Un directivo que es personalmente responsable del ciberriesgo y que no puede explicar, en lenguaje llano, qué significa su cuadro de mando de cumplimiento está expuesto. No porque el MSP fallara técnicamente; porque la brecha de adopción, entre la herramienta y la persona legalmente responsable del resultado, nunca se cerró. NIS2 no dice que los MSP deban convertirse en intérpretes de negocio. Pero hace imposible que cualquier consejero serio siga siendo un receptor pasivo de un Secure Score que no lee. ## De proveedor de TI a intérprete de negocio Aquí es donde el papel del MSP necesita evolucionar, y donde muchos MSP, con sinceridad, se sienten más incómodos. La implementación es terreno conocido. Ciclos de parches, líneas base, monitorización, respuesta a incidentes, SLA de tickets. El oficio técnico de operar un parque de TI es genuinamente difícil, y quienes lo hacen bien merecen más reconocimiento del que reciben. Lo que el oficio técnico no produce automáticamente es una conversación en la que un directivo entienda, en cinco minutos, contra qué está protegido, contra qué no lo está, cuánto costaría cerrar la brecha y qué le pasaría al negocio si esa brecha se explotara. Esa conversación es una habilidad distinta. Necesita a alguien capaz de situarse entre una consola de Microsoft Defender y una cuenta de resultados, y explicar por qué una afecta a la otra. Necesita a alguien cómodo diciendo: “Tu puntuación de cumplimiento es del setenta y ocho por ciento, aquí están los tres controles que faltan, y aquí está el contrato que podrías perder si una auditoría de un cliente los detecta”. Necesita que el MSP deje de vender herramientas y empiece a vender claridad. Unos pocos MSP de los mercados neerlandés, belga y alemán están construyendo discretamente esta capacidad dentro de sus propios equipos. La mayoría aún no. Los que lo hagan descubrirán que sus conversaciones de renovación se acortan y sus márgenes mejoran, porque el valor que entregan se vuelve visible para la persona que firma el cheque. A los que no lo hagan se les recordará como el proveedor cuyos cuadros de mando no leía nadie. ## Dónde encaja Guardian360 Dirijo un ISV que fabrica uno de esos cuadros de mando, así que sería deshonesto escribir esto sin abordar lo que hacemos y lo que no hacemos. Lighthouse produce los resultados técnicos habituales que produce cualquier herramienta de seguridad seria: resultados de escaneo en redes, IP y aplicaciones web, información de seguridad de Microsoft 365 a través de la Graph API, hallazgos de vulnerabilidades y recomendaciones de cumplimiento frente a más de cuarenta normas y leyes. Nada de eso es único. Lo que hemos dedicado los últimos años a construir, y lo que creemos que más importa para la conversación de este blog, es una puntuación de riesgo de negocio que se sitúa junto a las puntuaciones de riesgo técnico. El objetivo es simple: dar al consejo un número que conecte con el negocio, no solo con el activo. Una herramienta puede apoyar la conversación de traducción. No puede mantener la conversación. Ese es el trabajo del partner, y es donde dependemos, cada día, de los MSP, integradores y asesores que trabajan con nosotros. Las herramientas cierran una parte de la brecha de adopción. La relación cierra el resto. ## Una pregunta distinta que hacer en tu próxima revisión con el MSP Si eres directivo, dueño o miembro del consejo, no necesitas leer los artículos de NIS2 para actuar según lo que implican. En tu próxima revisión con tu partner de TI, no preguntes qué han implementado este trimestre. Pregunta si tú, tu equipo directivo e, idealmente, tu consejo entendéis lo que esas implementaciones significan para el negocio. Si la respuesta tarda más que el resumen de implementación, ya tienes tu hallazgo. La adopción de la seguridad empieza en el consejo, no en el helpdesk. El sector de los MSP, el sector de TI en general y los reguladores han empezado todos, a su manera, a empujar en la misma dirección. Los blogs y podcasts sobre la adopción por parte del usuario final son un comienzo saludable. La siguiente conversación, la más difícil, es sobre las personas cuyos nombres aparecen en lo más alto del organigrama y cuyas firmas acaban en la carta del regulador. Si esa conversación aún no ha ocurrido en tu organización, es la más útil que puedes agendar.