Guardian360
Empieza la prueba gratuitaHazte partner
← Todas las publicaciones

Opinión

MSP, NIS2 elevó el deber de diligencia de tu cliente. También elevó el tuyo.

Por Jan Martijn Broekhof ·

Mientras preparaba un webinar sobre la Cyberbeveiligingswet, la implementación neerlandesa de NIS2, hablé con Henk Bijsterbosch de Samen Digitaal Veilig. Mencionó algo que se me quedó grabado: el doble deber de diligencia aparece en casi todas las conversaciones que tiene con MSPs. No como un riesgo hipotético al que quizá algún día se enfrenten, sino como algo que ya está moldeando silenciosamente la forma en que clientes y MSPs discuten sobre quién era responsable de qué.

Esa conversación merece tenerse en serio, porque no es un problema neerlandés. La Cyberbeveiligingswet está en vigor en los Países Bajos desde el 15 de agosto de 2026. Bélgica transpuso NIS2 a su derecho nacional ya en octubre de 2024. La NIS2UmsuCG de Alemania entró en vigor el 6 de diciembre de 2025. Francia, en el momento de escribir esto, todavía no ha completado su transposición y ha sido remitida al Tribunal de Justicia de la UE por el retraso. Cuatro mercados, cuatro calendarios distintos, y una cosa que no espera a ninguno de ellos: el deber de diligencia del derecho civil que se aplica a los proveedores profesionales de TI y seguridad desde hace décadas, mucho antes de que nadie hubiera oído hablar de NIS2.

¿Qué es exactamente el doble deber de diligencia?

Hay dos capas, y los MSPs tienden a notar la primera y pasar por alto la segunda. La primera es el deber legal del cliente. NIS2, y sus implementaciones nacionales, ponen la responsabilidad de la gestión de riesgos, el registro y la notificación de incidentes directamente sobre la propia organización. La guía técnica de implementación de ENISA es explícita en que los proveedores de servicios gestionados y los proveedores de servicios de seguridad gestionados también entran dentro del ámbito de estos requisitos, lo cual es un recordatorio útil de que esto no es puramente una historia del lado del cliente.

La segunda capa es más antigua y fácil de pasar por alto precisamente porque es anterior a la regulación. En los Países Bajos, el articulo 7:401 del Codigo Civil neerlandes obliga a un proveedor profesional de servicios a actuar con la diligencia de un profesional competente, y la jurisprudencia neerlandesa ha sometido repetidamente a los proveedores de TI a un deber reforzado de información y advertencia por la brecha de conocimiento entre ellos y sus clientes, tal como expone la panorámica de Dirkzwager sobre las sentencias relevantes. Bélgica tiene su propia versión de esta doctrina: el Hof van Cassatie resolvió ya en 2006 que un proveedor de TI tiene el deber de informar, asesorar y advertir a su cliente, un principio que aún hoy se cita en la doctrina jurídica belga. Alemania llega a una conclusión similar a través de su propia jurisprudencia. Cuando el OLG Schleswig declaró responsable a un proveedor de servicios de TI por no asesorar adecuadamente a un cliente antes de contratar, y el Bundesgerichtshof rechazó admitir un recurso ulterior, confirmó un deber precontractual integral de informar y asesorar. La Cour de cassation de Francia ha resuelto lo mismo, que un proveedor de productos de TI complejos debe a su cliente un deber de asesoramiento, desde al menos 2006, y la Cour d’appel de Rennes aplicó ese principio directamente a un litigio de ciberseguridad en noviembre de 2024.

Cuatro países, cuatro sistemas jurídicos, la misma idea de fondo: NIS2 no inventó este deber. Solo elevó lo que está en juego si se ignora.

¿Por qué la responsabilidad del cliente no puede convertirse simplemente en problema del cliente?

Aquí es donde se sitúa la paradoja, y merece la pena detenerse en ella en lugar de pasarla por alto. NIS2 pone al cliente al volante. El cliente decide qué riesgo acepta, en qué invierte y cómo prioriza. Un MSP puede asesorar, pero no puede obligar a un cliente a actuar sobre ese asesoramiento. Hasta aquí, suena a que eso debería proteger al MSP.

No lo hace, y la razón es coherente en todas las jurisdicciones que revisé: la parte más experta carga con el deber más pesado, con independencia de quién firme el papeleo de cumplimiento. Un Tribunal de Apelación neerlandés, en un caso comentado por Elferink & Kortier Advocaten, fue aún más lejos, al sostener que un proveedor profesional de TI debe investigar activamente si las propias decisiones del cliente están de verdad justificadas, no limitarse a emitir una advertencia y seguir adelante. Tener razón en que la decisión correspondía al cliente no significa automáticamente que el MSP hiciera lo suficiente.

Cuando un cliente rechaza tu asesoramiento

Este es el patrón que la mayoría de los MSPs reconocen instintivamente, y se desarrolla más o menos igual en todas partes. Recomiendas una medida, EDR, gestión de parches, autenticación multifactor, algo que considerarías higiene básica. El cliente la rechaza, por razones de coste, por comodidad, o simplemente porque “nunca hemos tenido un problema.” Meses después, una autoridad de supervisión realiza una inspección, o peor, ocurre un incidente. El cliente, ahora expuesto a su propia responsabilidad legal bajo NIS2, busca a alguien con quien compartir la culpa, y el MSP que dio el asesoramiento es el candidato obvio. Como señala Critical.Matters, esta dinámica ya es visible en los Países Bajos incluso antes de que las obligaciones de la Cyberbeveiligingswet se hayan asentado del todo: los clientes trasladan las exigencias de seguridad por la cadena hacia sus proveedores mucho antes de cualquier acción de aplicación.

Cuando un cliente no quiere invertir en certificación

El segundo patrón es ligeramente distinto pero acaba en el mismo lugar. Un cliente se niega a obtener una certificación de seguridad reconocida, ya sea un marco de cadena de suministro alineado con NIS2, ISO 27001 o un estándar sectorial. Para que quede claro, la certificación no es un requisito legal para demostrar que tienes el control de tu propia seguridad; muchas organizaciones pueden demostrarlo mediante políticas documentadas, auditorías y un proceso de gestión de riesgos creíble. Pero un certificado es una forma rápida y externa de probarlo, ante una autoridad de supervisión, ante una aseguradora o ante un cliente tuyo que esté nervioso. Sin él, y sin una alternativa igual de convincente, una organización queda más expuesta cuando un gran cliente se marcha o un contrato se cae tras una revisión de seguridad. Una vez más, el MSP que señaló la carencia puede verse acusado de no haber presionado con suficiente fuerza.

La visión escéptica, y por qué no se sostiene

Sería justo preguntarse si esto no es simplemente miedo disfrazado de liderazgo de opinión, una forma conveniente de vender servicios de certificación o consultoría de cumplimiento. Entiendo el escepticismo. Pero el patrón descrito arriba no es especulación; está documentado en sentencias judiciales de cuatro sistemas jurídicos distintos, a lo largo de casi dos décadas. Lo que la jurisprudencia también muestra, de forma consistente, es que los MSPs que pueden señalar un rastro documental, asesoramiento documentado, decisiones del cliente registradas, un relato claro de qué se recomendó y qué se rechazó, salen de estos litigios en una posición mucho más sólida que quienes no pueden. El riesgo es real. También es, en la mayoría de los casos, gestionable.

¿Qué reduce de verdad el riesgo?

Esta es la parte tranquilizadora, y merece tanta atención como la advertencia. Tres cosas marcan la diferencia de forma consistente.

Documenta tu asesoramiento, y documenta la decisión del cliente cuando lo rechaza. No una nota vaga en un sistema CRM, sino algo lo bastante específico como para sostenerse meses o años después: qué recomendaste, por qué, y qué eligió hacer el cliente en su lugar.

Establece requisitos mínimos de seguridad antes de aceptar a un cliente, o antes de renovar, en vez de descubrir las carencias después de que algo salga mal. No se trata de ser difícil; se trata de ser honesto, pronto, cuando la relación todavía permite una conversación directa.

No dejes que “el cliente no lo quería” quede sin registrar. Es la única frase que determina si un litigio se convierte en una conversación compartida sobre el riesgo o en una discusión unilateral sobre la culpa.

Nada de esto exige que un MSP se convierta en un departamento jurídico. Exige tratar la documentación como parte del servicio, no como papeleo que se hace si queda tiempo.

Si quieres profundizar en esto, el 8 de octubre organizo un webinar para el mercado neerlandés sobre la Cyberbeveiligingswet, en el que cubro qué exige realmente y, con la misma importancia, cómo demostrar que tus medidas de seguridad funcionan en la práctica y no solo sobre el papel. Puedes inscribirte aquí.

Así que aquí va la pregunta que merece la pena hacerse esta semana: si un cliente te cuestionara mañana por un consejo que le diste hace dieciocho meses, ¿podrías realmente presentarlo?

Fuentes