Alrededor de 160.000 compañías europeas tendrán obligaciones directas bajo NIS2, diez veces más que con la normativa anterior. Para muchas PYMEs españolas que usan Dynamics 365 Business Central, esto no es una “norma más de ciberseguridad”: es el punto en el que el regulador entra, de facto, hasta el corazón de tu ERP y te pide trazabilidad, gobernanza y capacidad real de respuesta cuando algo sale mal.
Si eres director de operaciones, CFO o responsable de IT, NIS2 no te pregunta si te interesa; te pregunta cuánto riesgo quieres asumir a partir de ahora, sabiendo que las multas pueden llegar a 10 millones de euros o el 2 % de la facturación para entidades esenciales, y hasta 7 millones o el 1,4 % para las importantes.
1. NIS2: quién entra en el radar y por qué una PYME debería preocuparse
NIS2 (Directiva (UE) 2022/2555) es el nuevo marco europeo para elevar el nivel mínimo de ciberseguridad en 18 sectores críticos: energía, transporte, banca, salud, agua, infraestructuras digitales, servicios digitales, residuos, alimentación, fabricación de productos clave, entre otros. La lógica es sencilla: si tu actividad o la de tus clientes es crítica para la economía, ya no vale con “tener antivirus y copias de seguridad”; te obligan a demostrar gestión de riesgo seria.
En la práctica, la directiva se aplica, como norma general, a empresas medianas y grandes (a partir de 50 empleados y 10 millones de euros de facturación), aunque permite incluir empresas más pequeñas si son especialmente críticas o están en determinados eslabones de la cadena de suministro. Eso significa que muchas PYMEs españolas que usan Business Central entran de lleno como entidades “importantes”, y otras, aunque no estén directamente bajo NIS2, se verán presionadas por sus clientes regulados vía contratos, auditorías y requisitos de seguridad.
En España, el anteproyecto de ley NIS2 ya está aprobado, el régimen de sanciones está definido y la transposición avanza, aunque con retraso respecto a la fecha límite europea. Traducido: la discusión política puede moverse, pero el sentido de fondo no va a cambiar. Si estás esperando a que la ley esté “cerrada del todo” para actuar, vas tarde.
2. Del papel al ERP: por qué NIS2 se juega en Business Central
La directiva habla de medidas técnicas y organizativas “adecuadas y proporcionadas” para gestionar el riesgo de ciberseguridad: análisis de riesgo, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, pruebas y auditorías, criptografía, formación, control de accesos y uso de MFA, entre otras diez medidas mínimas.
En una PYME, el sistema que concentra más riesgo operativo y regulatorio es casi siempre el ERP:
Ahí se decide quién puede crear proveedores, cambiar cuentas bancarias o aprobar pagos. Se registra qué pedidos se han servido, qué lotes se han enviado y qué trazabilidad puedes demostrar a un auditor o a un regulador. Se cruzan usuarios internos, integraciones con otras aplicaciones, servicios en la nube y, muchas veces, terceros que acceden (consultores, outsourcers, etc.).
Por eso, si quieres tomarte NIS2 en serio, Business Central deja de ser “solo un sistema de gestión” y pasa a ser un activo regulado: tienes que poder demostrar cómo lo proteges, cómo lo monitorizas y cómo reaccionas ante incidentes que lo afecten.
3. Gobernanza y roles: del “usuario genérico” a la responsabilidad personal
NIS2 introduce una idea que preocupa (y con razón) a cualquier comité de dirección: la responsabilidad de la alta dirección en materia de ciberseguridad. Los administradores pueden responder personalmente si no ponen los medios razonables para gestionar el riesgo.
A nivel de ERP, esto exige dejar atrás el modelo de “IT decide los permisos y el resto confía” y pasar a un modelo con más responsabilidad de negocio:
Por un lado, necesitas propietarios de proceso: el CFO es responsable de cómo se usan los módulos financieros; el director de operaciones, de compras, producción o logística; cada uno define qué se puede y qué no se puede hacer desde el ERP en su área. Por otro, hace falta una gobernanza de roles clara: al menos una vez al año (NIS2 te empuja a hacerlo con más frecuencia), revisas y apruebas formalmente qué puede hacer cada rol en Business Central, quién tiene permisos de administrador y qué accesos son “de emergencia” con controles adicionales.
Y, en el centro de todo, la segregación de funciones (SoD): nadie debería ser capaz de diseñar el fraude perfecto desde un único usuario. El mismo rol no debería poder crear un proveedor, cambiarle el IBAN y autorizar el pago. Esto se resuelve combinando roles bien definidos, flujos de aprobación y, cuando hace falta, extensiones específicas.
Si hoy sigues teniendo usuarios tipo “CONTABILIDAD”, compartidos entre tres personas, o “ALMACEN” con acceso global, no estás lejos de NIS2: estás en las antípodas.
4. Aterrizando las medidas de NIS2 en Business Central
4.1. Segregación de funciones y control de acceso
Una de las diez medidas mínimas de NIS2 agrupa seguridad de recursos humanos, control de accesos y gestión de activos como elementos obligatorios de la gestión de riesgo. En Business Central esto se traduce en tres decisiones operativas muy concretas.
Primero, diseñar una matriz de roles basada en tareas de negocio, no en personas. En lugar de “usuario de administración”, deberías tener roles como “AP – registro de facturas”, “Tesorería – ejecución de pagos”, “Compras – altas de proveedores”, cada uno con permisos mínimos necesarios (principio de mínimo privilegio).
Segundo, reforzar la segregación de funciones crítica: por ejemplo, que la persona que da de alta un proveedor no sea quien modifica sus datos bancarios ni quien ejecuta el pago. Estas restricciones se configuran combinando permisos, flujos de aprobación y, cuando hace falta, reglas adicionales vía extensiones o soluciones de terceros si el estándar no te llega.
Tercero, gestionar los superusuarios como un riesgo en sí mismo. NIS2 no prohíbe los administradores, pero espera que su uso sea excepcional, trazado y revisado. En Business Central conviene limitar el rol de “SUPER” a muy pocas cuentas, con accesos revisados y uso restringido a tareas claramente definidas (parametrización, emergencia, etc.).
4.2. MFA y autenticación reforzada: puerta de entrada bajo control
Otra de las medidas explícitas en NIS2 es el uso de autenticación multifactor o mecanismos equivalentes. No es opcional ni “recomendable”: es baseline.
Con Business Central online, el camino es muy claro: el ERP se integra con Microsoft Entra ID (antes Azure AD), donde puedes exigir MFA para todos los usuarios o, como mínimo, para roles sensibles, mediante políticas de acceso condicional. Técnicamente es sencillo, pero a nivel de negocio implica varias decisiones que suelen bloquear proyectos.
En primer lugar, implica eliminar usuarios compartidos: cada usuario debe ser nominal, con su propio factor adicional (app de autenticación, SMS, llamada, llave física…). En segundo lugar, te obliga a formalizar un procedimiento para altas, bajas y cambios: cuando alguien entra, se mueve de puesto o se va, sus credenciales y factores deben activarse, adaptarse o revocarse de forma controlada y documentada. Por último, obliga a gestionar los accesos externos (consultores, partners, BPO) con su propia identidad, nunca con usuarios internos “prestados”.
Desde la perspectiva de un CFO o COO, la pregunta incómoda pero honesta es: “¿Hoy podría un ex empleado seguir entrando a nuestro Business Central desde su casa sin que nadie se dé cuenta?”. Si la respuesta no es un “no” rotundo, tienes un incumplimiento material de las exigencias de NIS2.
4.3. Auditorías y logs: menos ruido, más evidencia útil
NIS2 insiste en la necesidad de registros que permitan detectar incidentes y reconstruir lo sucedido, así como en la evaluación periódica de la eficacia de las medidas de seguridad. En Business Central, el reto no es solo activar logs, sino diseñarlos para que realmente sirvan.
Operativamente, tiene sentido separar tres capas de registro:
Por un lado, un change log funcional: qué cambios se han hecho en tablas relevantes (por ejemplo, datos maestros de clientes, proveedores, productos, cuentas bancarias, usuarios). Aquí es donde demuestras quién cambió el IBAN de un proveedor antes de un fraude.
Por otro, la telemetría técnica: eventos de sesión, errores, ejecuciones anómalas, integraciones que fallan… Business Central puede enviar telemetría a servicios de monitorización o a un SIEM corporativo, donde se cruzan señales de ERP con otros sistemas para detectar comportamientos sospechosos.
Finalmente, las trazas de administración: quién crea usuarios, quién asigna permisos, quién restaura copias, quién cambia parámetros clave. Esta capa es crítica para demostrar que no hay uso abusivo de privilegios.
El error típico es activar el change log “a lo bruto” y acabar con millones de entradas imposibles de revisar. El enfoque alineado con NIS2 es definir qué procesos son críticos y registrar solo aquello que soporta tus casos de detección y auditoría, con políticas claras de retención y revisión periódica.
4.4. Copias de seguridad e inmutabilidad: diseñar para el ransomware
El regulador asume que el ransomware y otros incidentes graves no son una posibilidad remota, sino un escenario a gestionar. NIS2 exige medidas de continuidad de negocio, incluidas copias de seguridad robustas y recuperables.
Aquí conviene recordar una verdad incómoda: en entornos Microsoft 365, Microsoft garantiza la disponibilidad del servicio, pero no sustituye la responsabilidad de tus copias de seguridad, y la recomendación de buenas prácticas es externalizar backups y dotarlos de inmutabilidad.
En Business Central, el mínimo razonable en clave NIS2 para una PYME sería algo como esto: si estás en Business Central SaaS, complementar las capacidades nativas de Microsoft con una solución de backup externa que exporte datos y, cuando proceda, snapshots a almacenamiento inmutable (por ejemplo, blob con bloqueo de escritura) en otra suscripción o incluso otro proveedor cloud. Si estás en Business Central on-prem, aplicar una estrategia 3-2-1 (tres copias, dos soportes, una off-site), automatizada y probada, con al menos un repositorio inmutable o aislado lógicamente del dominio de Windows.
En ambos casos necesitas documentar y probar un RTO/RPO realista para el ERP: cuánto tiempo puedes estar sin Business Central y cuántos datos puedes permitirte perder. Si el negocio no ha asumido estos tiempos por escrito, el día del incidente la discusión será caótica. Desde la óptica de NIS2, no se trata solo de “tener copias”, sino de poder demostrar que las copias no son vulnerables al mismo ataque y que tienes procedimientos de restauración ensayados.
4.5. Gestión de vulnerabilidades y parches: más que “instalar actualizaciones cuando haya tiempo”
Otra de las áreas clave listadas en el artículo 21 de NIS2 es la gestión de vulnerabilidades, lo que incluye adquisición, desarrollo y mantenimiento seguro de sistemas, así como pruebas y auditorías periódicas.
En Business Central esto tiene dos realidades muy distintas. En BC online, Microsoft se encarga de parches de plataforma, sistema operativo y base de datos. Pero tú sigues siendo responsable de tus extensiones, integraciones y configuración de seguridad, y de validar en entornos de pruebas que las actualizaciones no rompen tu modelo de control. En BC on-prem, el problema es más clásico y más duro: parches de sistema, base de datos, aplicación, antivirus, hardening del servidor… todo recae en tu equipo o en tu proveedor.
En ambos casos, alinearse con NIS2 implica pasar de “actualizamos cuando hay un problema” a tener un calendario de parches definido (mensual o trimestral) y priorizado por criticidad, un inventario de activos ERP (servidores, bases de datos, add-ons, integraciones) ligado a un ciclo de evaluación de vulnerabilidades, al menos para los componentes expuestos a internet, y pruebas de regresión básicas en un entorno sandbox antes de subir parches al entorno productivo, especialmente cuando afectan a módulos críticos (finanzas, almacén, producción).
La pregunta pragmática es sencilla: si mañana se publica una vulnerabilidad crítica en un componente que afecta a tu ERP, ¿tu organización sabe quién decide cuándo y cómo parchear, y en qué orden? Si la respuesta es “depende de si el proveedor tiene hueco”, estás lejos del estándar de NIS2.
4.6. Planes de respuesta a incidentes con foco en ERP
NIS2 endurece las obligaciones de notificación de incidentes: aviso inicial en 24 horas, informe detallado en 72 horas y evaluación final en un plazo aproximado de 30 días para entidades esenciales, con esquemas similares para las importantes. Eso solo es posible si tienes un plan realista, no un PDF olvidado.
A nivel de ERP, un plan de respuesta mínimamente serio debería contemplar, como mínimo, tres escenarios: compromiso de credenciales de un usuario con permisos elevados en Business Central (por phishing, malware, etc.), corrupción o borrado masivo de datos (intencionado o accidental) que afecte a contabilidad, inventario, pedidos o producción, e impacto de ransomware o incidente mayor en la infraestructura donde vive BC (si eres on-prem o IaaS), que deja el ERP no disponible o cuestiona la integridad de los datos.
Para cada escenario, necesitas definir quién declara el incidente, quién decide parar procesos (por ejemplo, pagos o expediciones), cómo se “congela” la evidencia (logs, copias, trazas) y cómo se coordina la comunicación con autoridades y clientes afectados. Si hoy tu organización no puede responder con nombres y tiempos a estas preguntas alrededor del ERP, NIS2 te está señalando un área de debilidad clara.
5. Sectores típicos y casos reales en PYMEs españolas
En el contexto español, hay varios tipos de PYMEs usuarias de Business Central que se cruzan de lleno con NIS2. Por ejemplo, fabricantes industriales que forman parte de la cadena de suministro de sectores críticos (energía, transporte, salud, alimentación, agua, residuos), muchos de ellos clasificados como entidades importantes por tamaño y actividad. También encontramos operadores logísticos que prestan servicios a empresas reguladas (por ejemplo, distribución farmacéutica, transporte alimentario) y proveedores de servicios digitales (SaaS verticales, hosting sectorial, MSPs) que gestionan infraestructuras o datos de entidades esenciales o importantes, quedando directa o indirectamente en el ámbito de NIS2.
Pongamos un caso sencillo: fabricante de componentes para el sector energético, 80 empleados, 20 millones de euros de facturación, Business Central como ERP centralizado. Cumple el umbral de tamaño, opera en una cadena de suministro crítica y sus clientes energéticos empiezan a exigir garantías de seguridad y cláusulas de ciberresponsabilidad. Aquí NIS2 deja de ser una abstracción jurídica: si un atacante manipula las órdenes de producción o los datos de calidad en el ERP y eso impacta en el suministro del cliente, el incidente y las responsabilidades se rastrean hasta tu sistema. Y lo que mirarán será si tus controles de acceso, respaldos, logs y planes de respuesta estaban a la altura.
6. Checklist práctica para arrancar en tu ERP
Si quieres empezar a moverte en serio, esta es una plantilla de checklist mínima, pensada para que la completes junto con IT y los responsables de proceso. No es exhaustiva, pero si aquí salen demasiados “no” o “no lo sé”, ya tienes tu hoja de ruta.
Gobernanza y roles
- ¿Tenemos identificados, por escrito, los propietarios de cada área funcional del ERP (finanzas, compras, ventas, logística, producción)?
- ¿Existe una matriz de roles de Business Central aprobada por negocio, no solo por IT?
- ¿Revisamos al menos una vez al año los permisos efectivos de los usuarios y roles críticos?
Segregación de funciones y acceso
- ¿Hay usuarios compartidos o genéricos en el ERP?
- ¿Puede una sola persona crear un proveedor, cambiarle el IBAN y autorizar pagos desde su usuario normal?
- ¿Tenemos flujos de aprobación configurados para operaciones sensibles (altas de maestro, pagos, descuentos fuera de política)?
Autenticación y MFA
- ¿Todo acceso remoto a Business Central utiliza identidades nominales con MFA obligatorio para usuarios internos y externos?
- ¿Hay un procedimiento formal para altas, bajas y cambios de usuarios, con revocación de accesos en tiempo razonable cuando alguien se va?
Logs y auditoría
- ¿Tenemos activado el change log en tablas críticas (proveedores, clientes, cuentas bancarias, usuarios, parámetros clave)?
- ¿Sabemos quién revisa esos logs y con qué frecuencia?
- ¿La telemetría del ERP se integra en algún sistema centralizado de monitorización o SIEM?
Copias de seguridad y recuperación
- ¿Disponemos de copias de seguridad externas y, al menos una, en almacenamiento inmutable o segregado?
- ¿Hemos probado en los últimos 12 meses una restauración completa de Business Central en un entorno de prueba, midiendo tiempos y validando datos?
Vulnerabilidades y parches
- ¿Existe un inventario actualizado de componentes del ecosistema ERP (servidores, BBDD, add-ons, integraciones)?
- ¿Tenemos un calendario de actualización y parches acordado entre IT y negocio?
Respuesta a incidentes
- ¿Hay un plan de respuesta a incidentes que contemple específicamente escenarios que afecten al ERP?
- ¿Al menos una vez al año simulamos un incidente relevante (por ejemplo, compromiso de un usuario financiero o caída prolongada del ERP) para ver si los tiempos y decisiones son realistas?
7. Y ahora qué: NIS2 como coste hundido o como palanca de control
NIS2 no va a desaparecer, y tampoco se va a relajar con el tiempo. El regulador ha decidido que la ciberseguridad, y, por extensión, el control sobre sistemas como tu ERP, deje de ser un tema interno y pase a ser cuestión de cumplimiento, responsabilidad y, llegado el caso, sanción.
Puedes abordarlo como un coste hundido (“cumplamos lo justo para no tener problemas”) o aprovechar el golpe de realidad para hacer algo que llevas años posponiendo: ordenar roles, limpiar accesos históricos, profesionalizar backups, documentar escenarios de crisis y, en definitiva, elevar el nivel de control real que tienes sobre Business Central.
Si quieres que NIS2 juegue a tu favor, el primer paso no es escribir una política más, sino reservar tiempo de dirección. Pon en la agenda de este mes una sesión conjunta CFO–COO–IT con el checklist delante y responde, sin maquillaje, a cada punto. Todo aquello que hoy no puedas explicar en cinco minutos a un auditor razonablemente exigente es, en la práctica, tu backlog prioritario de proyecto sobre el ERP. Y cuanto antes lo ataques, menos caro, y menos doloroso, será cuando el próximo incidente deje de ser una hipótesis y se convierta en la llamada que nadie quiere recibir.
