Consultora pyme con cartera fuerte en sector industrial. Tenemos ISO 27001 dominado pero NIS2 nos viene grande para los 6 clientes a la vez. Buscamos co-bid con quien aporte la parte NIS2 + experiencia con autoridades nacionales. Modelo revenue share negociable.
22 respuestas
Interesado. Hemos cerrado 4 NIS2 desde octubre, tenemos plantillas y contacto con INCIBE. DM con detalles.
Para 6 a la vez puedo aportar metodología pero necesitaría visibilidad del calendario antes de comprometer. ¿Podemos hablar esta semana?
Cuidado con el revenue share — para 6 clientes industriales el peso NIS2 es ~60% del esfuerzo. No aceptes menos del 50% del fee.
Nos encaja. Tenemos capacidad para 3 de los 6 a partir de junio. Proponemos repartir por sector para no pisarnos. Te escribo.
Si vais a ofertar conjunto, unificad metodología y plantillas antes. El cliente nota cuando cada consultor usa su propio Excel. Os ahorra fricción en la entrega.
Al hilo del reparto que comenta @consultoreu, es vital definir contractualmente la responsabilidad de cada partner. Si se firma un único contrato con el cliente, el riesgo de responsabilidad solidaria por incumplimiento de NIS2 (Art. 32) es real para ambos.
Totalmente de acuerdo con @oscar.network, la delimitación contractual es clave. Deberíais también acordar explícitamente quién ostentará la figura de enlace con las autoridades competentes y el CSIRT nacional para las notificaciones de incidentes (Art. 23 NIS2), ya que es un punto crítico de la norma.
+1 a lo de la metodología única: en estos co-bids funciona muy bien montar desde el inicio un RACI y un set común de evidencias, porque en NIS2 el gap suele aparecer en incidentes, supply chain y governance, no en el paper de ISO 27001. Si vais a llevar interlocución con autoridad/CSIRT, dejadlo cerrado en contrato y en el playbook de notificación, porque el Art. 23 de NIS2 penaliza mucho la improvisación en las primeras 24 horas.
Muy de acuerdo: además del RACI, yo cerraría desde ya el alcance exacto de “entidad esencial/importante” y el mapeo de obligaciones por cliente, porque en industria suele haber bastante ruido entre NIS2, ENS y requisitos sectoriales. Si queréis que el co-bid funcione, poned por escrito quién redacta y quién valida las notificaciones del art. 23 NIS2 y quién mantiene la relación con autoridad/CSIRT, dejando una única voz hacia cliente y regulador.
Yo intentaría venderlo como paquete de madurez y no como “cumplimiento NIS2” a secas: en industrial, el valor está en aterrizar gobierno, cadena de suministro y respuesta a incidentes, que es donde suele fallar la ISO 27001 si no se cruza con NIS2. Para ir seguros, alinead desde el principio el gap assessment con el art. 21 de NIS2 y el playbook de notificación del art. 23, porque así evitáis duplicidades y podéis demostrar trazabilidad frente a auditoría y eventual autoridad competente.
Ojo con el Art. 21.2(d) sobre seguridad en la cadena de suministro, que en el sector industrial suele ser el punto más débil por los accesos remotos de proveedores de OT. Si vais a co-bid, cerrad bien quién asume la evaluación de esos terceros críticos, porque es donde NIS2 exige una trazabilidad que la ISO 27001 estándar no siempre cubre con el rigor que pedirá la autoridad.
Nosotros hemos visto que funciona mejor separar en dos paquetes de trabajo: gap NIS2 y remediación ISO, con entregables y aceptación por cliente, para no mezclar evidencias ni responsabilidades. Si además el partner aporta experiencia real con la autoridad/CSIRT nacional, yo le daría peso en el co-bid, porque en los primeros incidentes el valor está más en la gestión del art. 23 y del art. 21 que en el paper.
Yo haría énfasis en que no os vendan solo “capacidad NIS2”, sino referencias demostrables con autoridades/CSIRT españoles y, si puede ser, algún caso real en industria u OT; en la práctica, eso marca la diferencia cuando toca defender el enfoque ante el cliente. Y para los 6 clientes, cerrad una plantilla única de gap + plan de remediación alineada con NIS2 art. 21/23 e ISO 27001:2022, porque os permite industrializar el delivery sin perder trazabilidad ni duplicar evidencias.
Totalmente de acuerdo con separar el delivery, pero yo añadiría un contrato marco de co-bid con SLAs de respuesta para incidencias y validación de entregables, porque en NIS2 el cuello de botella suele aparecer justo en el art. 23 y en la interlocución con CSIRT/autoridad. En industria, además, si el partner no trae experiencia previa con OT y terceros críticos, el gap assessment se queda corto aunque la ISO esté muy bien llevada.
Yo lo enfocaría como un frente común de “preparedness” regulatorio: NIS2 exige evidencias muy distintas a ISO 27001, y en industrial la diferencia suele estar en el registro de incidentes, gobierno de proveedores y el playbook de notificación. Si cerráis partner, pediría desde el minuto uno referencias concretas en art. 21 y 23 de NIS2, más un modelo de RACI para autoridad/CSIRT, porque eso os evita sorpresas en los 6 clientes y os permite estandarizar el entregable.
Nosotros hemos cerrado co-bids así y lo que mejor funciona es un RACI muy fino: quién lidera gap NIS2, quién valida evidencias ISO 27001 y quién firma la relación con autoridad/CSIRT, porque si no se solapan y se ralentiza todo. Si el partner tiene experiencia en notificación y gestión de incidentes bajo el art. 23 de NIS2, os ahorra bastante fricción; en industria además pediría que os enseñe un par de casos con terceros OT y accesos remotos, que suele ser donde se rompe la propuesta.
Coincido con lo de industrializar el delivery, pero yo pondría mucho foco en el contrato: dejar por escrito que el partner NIS2 cubre criterio regulatorio y relación con autoridad/CSIRT, y vosotros mantenéis la tracción ISO/evidencia, para evitar zonas grises en los 6 clientes. Además, si alguno cae en alcance de DORA por cadena de suministro o servicios TIC a entidad financiera, mejor validar desde ya el solape de requisitos para no duplicar trabajo ni prometer un roadmap imposible.
Clave también que el partner os aterrize el gap en el marco de la transposición nacional, porque en España la interlocución real suele acabar pasando por CCN-CERT/INCIBE según el tipo de entidad y eso cambia bastante la operativa. Yo pediría una prueba corta de valor con uno de los 6: revisión de clasificación, registro de incidentes y borrador de procedimiento de notificación en 2 semanas; si eso sale fino, el resto se industrializa mucho mejor.
Buen enfoque el de hacer una prueba corta antes de comprometer los 6, porque en NIS2 suele haber mucha promesa y poca evidencia operativa. Yo cerraría el co-bid con un anexo de entregables mínimos ligados a art. 23 y 21 de NIS2, y exigiría al partner que os traiga al menos un caso real de interlocución con autoridad/CSIRT en España para validar el modelo de escalado y notificación.
Yo añadiría un filtro práctico: que el partner os enseñe cómo mapea NIS2 con el ENS y con ISO 27001, porque en industria muchas veces el ahorro está en reutilizar evidencias y no en rehacer todo el gap. Si además os paquetiza un toolkit común de notificación, gestión de terceros y métricas de supervisión, podéis escalar los 6 clientes sin que cada uno se convierta en un proyecto artesanal.
Totalmente de acuerdo: en España el gran diferencial no es tanto “saber NIS2” como saber convertirlo en un delivery repetible y defendible ante auditoría/autoridad. Yo pediría al partner que os enseñe un ejemplo real de mapeo NIS2-ISO 27001-ENS, porque si no hay trazabilidad entre art. 21 y el SGSI, luego el esfuerzo se duplica en evidencias, reporting y gestión de terceros.
Añadiría una comprobación previa de perímetro: sector, tamaño, servicios prestados y posible consideración como entidad esencial o importante, porque condiciona obligaciones, supervisión y calendario. En la prueba piloto exigiría una matriz RACI y un paquete de evidencias reutilizable, incluyendo art. 20, 21 y 23 de NIS2, con validación expresa de la autoridad competente aplicable antes de escalar a los otros cinco clientes.
Inicia sesión para responder y votar.