GRCreal // expediente: artículo categoría: GRC
← Volver a artículos
GRC · Continuidad · Dirección

¿Sabe el comité de dirección qué es un SGCN?

La continuidad de negocio no es un proyecto de IT.
Es una decisión estratégica. Y empieza arriba.

Miguel Ángel Carriazo 13 mayo 2026 12 min de lectura
El punto de partida

Una pregunta incómoda

Llevo años entrando en organizaciones para hablar de continuidad de negocio. Y hay una pregunta que hago siempre antes de empezar: ¿el comité de dirección sabe qué es un SGCN?

La respuesta más frecuente no es un no rotundo. Es algo peor: una respuesta ambigua. "Tenemos un plan de recuperación." "IT se encarga de los backups." "Creo que Recursos Humanos tiene algo de protocolos de crisis."

Eso no es un Sistema de Gestión de la Continuidad de Negocio. Es un conjunto de documentos dispersos que nadie ha conectado entre sí, que nadie ha probado, y que en una crisis real serían tan útiles como nada.

El SGCN no falla porque IT no haga bien su trabajo. Falla porque dirección nunca entendió qué estaba aprobando.
Curva de recuperación · GRC
La continuidad se mide contra el impacto
IMPACTORECUPERACIÓNINTERRUPCIÓNOBJETIVOUna pregunta incómodaEl SGCN explicado sin jergaLa empresa que "tenía…Cuando el proveedor era…Por qué esto no puede…
No basta con tener copia o plan: el tiempo, la pérdida asumible y la recuperación real deben encontrarse.
Qué es realmente

El SGCN explicado sin jerga

Un Sistema de Gestión de la Continuidad de Negocio — basado en la norma ISO 22301 — es el conjunto de políticas, procesos, planes y capacidades que permiten a una organización seguir operando sus funciones críticas cuando algo sale muy mal.

"Algo muy mal" puede ser: un incendio en el centro de datos, un ransomware que cifra los sistemas de producción, la caída de un proveedor crítico durante días, la baja simultánea de personal clave por una pandemia, o una inundación que deja la sede inaccesible durante semanas.

El SGCN responde a tres preguntas fundamentales que dirección debe poder contestar:

¿Cuáles son los procesos de negocio que no pueden parar bajo ninguna circunstancia — o que si paran, cuánto tiempo puede soportar la organización?

¿Qué recursos (tecnología, personas, proveedores, instalaciones) sostienen esos procesos y qué pasa si fallan?

¿Qué hacemos exactamente, quién decide qué y en qué orden, cuando eso ocurre?

No son preguntas técnicas. Son preguntas de negocio. Y sus respuestas las tiene — o debería tener — el comité de dirección, no el departamento de IT.
Lectura operativa GRCREAL
Qué entender

Una pregunta incómoda. Delimita el problema antes de elegir una respuesta.

Qué comprobar

El SGCN explicado sin jerga. Busca una práctica observable, no solo una declaración.

Qué poder demostrar

ISO 22301, NIS2 y ENS: todos apuntan arriba. La decisión y su revisión deben dejar trazabilidad.

Un ejemplo real

La empresa que "tenía todo cubierto"

Una empresa de distribución mediana, unos 200 empleados, operaciones en tres provincias. Cuando les pregunté por su continuidad, el director de IT me mostró orgulloso su arquitectura de backup: réplica diaria a cloud, retención de 30 días, snapshots cada 4 horas. Todo correcto técnicamente.

Entonces le pregunté: ¿cuánto tiempo puede estar el sistema de gestión de pedidos caído antes de que perdáis clientes de forma irreversible? No lo sabía. ¿Quién toma la decisión de activar el modo de contingencia? No estaba claro. ¿Los equipos de ventas saben operar en modo manual si los sistemas no están disponibles 48 horas? Nunca se había planteado.

El departamento de IT había construido una excelente capacidad de recuperación tecnológica. Pero nadie había hecho el análisis de impacto de negocio que permitiera saber qué recuperar primero, en qué orden y con qué urgencia. El sistema de pedidos y el servidor de impresión de nóminas tenían la misma prioridad de recuperación — ninguna.

Cuando sufrieron un incidente semanas después — un fallo de hardware que dejó los sistemas caídos 18 horas — recuperaron primero lo que técnicamente era más fácil, no lo que el negocio necesitaba. El coste no fue tecnológico. Fue comercial.
Otro ejemplo

Cuando el proveedor era el plan

Una firma de servicios profesionales, sector legal, con toda su operativa — gestión documental, facturación, comunicaciones — alojada en un único proveedor SaaS. Contrato estándar, sin SLA de disponibilidad garantizada más allá del 99,5% mensual.

El cálculo que nadie había hecho: 99,5% de disponibilidad mensual equivale a hasta 3,6 horas de caída al mes — perfectamente dentro del contrato. Para ellos, 3,6 horas sin acceso a expedientes en un día de juicios o cierres de operación podía ser catastrófico.

Cuando pregunté al comité qué hacían si ese proveedor no estaba disponible durante un día completo, la respuesta fue: "llamamos a soporte." No había plan de trabajo alternativo. No había copia local de los expedientes activos. No había protocolo de comunicación con clientes.

Su SGCN era, en la práctica, confiar en que el proveedor no fallara. Eso no es continuidad. Es optimismo.
El papel de dirección

Por qué esto no puede delegarse a IT

Un SGCN requiere decisiones que solo dirección puede tomar. No porque sean técnicas — precisamente porque no lo son.

El Análisis de Impacto de Negocio (BIA) pregunta: ¿cuánto dinero, reputación o cumplimiento normativo pierdes por cada hora que cada proceso crítico está caído? Esa respuesta la tiene el director financiero, el director comercial, el director de operaciones. No el responsable de sistemas.

La definición de RTO (tiempo máximo de recuperación) y RPO (máxima pérdida de datos asumible) son decisiones de apetito al riesgo. El negocio decide cuánto puede perder. IT implementa los mecanismos para cumplirlo. El orden importa: primero decide negocio, luego ejecuta IT.

La activación del plan de continuidad durante una crisis real implica decisiones sobre comunicación a clientes, relación con medios, notificación a reguladores, posible paralización de actividad. Esas decisiones son del CEO, del director jurídico, del responsable de comunicación. No del técnico de guardia.

Cuando la crisis llega — y llega — no hay tiempo para que dirección aprenda qué es un SGCN. O ya lo sabe, o improvisa. Y la improvisación en una crisis siempre es más cara que la preparación.
Evidencia operativa

Qué esperaría encontrar para demostrar que esto funciona

La evidencia concreta depende del alcance y del contexto de la organización. Aun así, una revisión seria debería poder reconstruir al menos estas tres capas:
Ref.Capa de evidenciaQué debería permitir comprobar
EV-01Propietario y decisión documentadaQuién es responsable, qué alcance se ha definido y qué decisión se ha tomado.
EV-02Registro de riesgo o excepciónQue el control o proceso se aplica sobre casos reales y no existe únicamente en la documentación.
EV-03Revisión y seguimiento de eficaciaQue las desviaciones se detectan, se corrigen y vuelven a revisarse con una frecuencia razonable.
El marco normativo

ISO 22301, NIS2 y ENS: todos apuntan arriba

ISO 22301 — la norma internacional para SGCN — establece en su cláusula 5 el liderazgo y compromiso de la alta dirección como requisito no delegable. No como buena práctica. Como requisito de certificación.

NIS2 obliga a los órganos de dirección de las entidades esenciales e importantes a aprobar las medidas de gestión de riesgos de ciberseguridad — incluida la continuidad — y supervisar su implantación. Y establece responsabilidad personal: los miembros del órgano de dirección pueden ser declarados responsables en caso de incumplimiento.

El ENS, en su dimensión de disponibilidad, exige que la continuidad del servicio esté integrada en la gestión de la organización, no solo en el departamento técnico.

Los tres marcos normativos más relevantes en España convergen en el mismo punto: la continuidad de negocio es responsabilidad de dirección. No una responsabilidad que dirección puede firmar y delegar — una responsabilidad que dirección debe entender, aprobar y supervisar activamente.
Guía de aplicación

Cómo llevar «¿Sabe el comité de dirección qué es un SGCN?» a un modelo operativo

El error habitual al abordar este tema es convertirlo demasiado pronto en un documento o en una lista de tareas. En GRC, yo lo llevaría primero a un modelo operativo verificable: qué queda dentro del alcance, quién puede decidir, qué condiciones activan una revisión y qué rastro queda después de cada actuación.

Para este caso partiría de información para decidir. No porque sea el único punto importante, sino porque permite fijar el contexto antes de discutir controles. A partir de ahí conectaría riesgos y desviaciones relevantes con la realidad del proceso o activo gobernado y cerraría el ciclo con acuerdos, recursos y seguimiento.

La pregunta que utilizaría para probar la madurez sería sencilla: ¿puede una persona que no participó en el proyecto reconstruir la decisión, entender el riesgo y localizar la evidencia sin depender de una explicación oral? Si la respuesta es no, existe conocimiento, pero el gobierno todavía depende de personas concretas.

Mi enfoque

No intentaría implantar todo de una vez. Seleccionaría un caso representativo, documentaría la cadena contexto, riesgo, decisión, control y evidencia y comprobaría dónde se pierde la trazabilidad.

El primer objetivo no sería «tener más documentación», sino conseguir que el propietario del riesgo y dirección pueda demostrar qué decidió, por qué lo decidió y cómo sabe que el control sigue funcionando.

Plano de revisiónQué comprobaríaSeñal de debilidadEvidencia útil
ContextoInformación para decidir; límites, dependencias y supuestos.El alcance cambia según quién lo explique.Ficha de alcance, inventario o mapa de dependencias vigente.
GobiernoPropietario, capacidad de decisión, escalado y excepciones.IT ejecuta, pero nadie de negocio acepta el riesgo.RACI, acta, ticket de decisión o registro de aceptación.
ControlRiesgos y desviaciones relevantes; diseño, cobertura y operación real.Se describe el control, pero no su población ni frecuencia.Configuración, procedimiento, muestra de ejecución y resultado.
SupervisiónAcuerdos, recursos y seguimiento; umbrales, desviaciones y revisión.Solo se revisa cuando llega una auditoría o un incidente.KPI/KRI, revisión periódica, hallazgo y acción de mejora.
Secuencia de trabajo
01 · Reconstruir

Utilizar «Una pregunta incómoda» como punto de entrada para describir la realidad actual, incluidas excepciones y dependencias que no aparecen en el procedimiento.

02 · Contrastar

Tomar «El SGCN explicado sin jerga» y comprobarlo con una muestra real. La documentación debe coincidir con usuarios, activos, configuraciones, decisiones o registros.

03 · Cerrar el ciclo

Relacionar «La empresa que "tenía todo cubierto"» con un responsable, una fecha y una evidencia de revisión. Una desviación sin seguimiento es información, no gobierno.

Revisión crítica

Diez preguntas que utilizaría para revisar este tema

Estas preguntas no sustituyen una auditoría ni una evaluación formal. Sirven como prueba rápida de coherencia: si varias respuestas dependen de «creo», «normalmente» o «lo lleva otra persona», ya existe una línea de trabajo.

  1. ¿Qué está exactamente dentro del alcance? Debe poder delimitarse el proceso o activo gobernado sin recurrir a una descripción ambigua.
  2. ¿Quién es el propietario real? El propietario del riesgo y dirección debe conocer su responsabilidad y tener capacidad para escalar o decidir.
  3. ¿Qué escenario de riesgo estamos intentando evitar o limitar? Un control sin escenario asociado se evalúa por presencia, no por eficacia.
  4. ¿Qué depende de información para decidir? Hay que identificar supuestos, datos de entrada, servicios y terceros que cambian la exposición.
  5. ¿Cómo sabemos que riesgos y desviaciones relevantes funciona sobre toda la población? Una muestra positiva no demuestra cobertura completa.
  6. ¿Qué excepciones existen hoy? Deben tener propietario, motivo, riesgo aceptado, compensación y caducidad cuando proceda.
  7. ¿Qué evidencia queda después de ejecutar el control? La evidencia debe ser recuperable, fechada y entendible por una tercera persona.
  8. ¿Qué indicador obliga a actuar? Medir sin umbral, tendencia o decisión asociada termina creando cuadros de mando decorativos.
  9. ¿Cuándo se revisó por última vez acuerdos, recursos y seguimiento? El cambio de contexto puede invalidar una decisión que era razonable seis meses antes.
  10. ¿Qué aprendimos de la última desviación? Si el hallazgo se cierra corrigiendo el síntoma y no cambia el sistema, probablemente volverá.
Pregunta incómoda

Si mañana la persona que domina este tema deja la organización, ¿el sistema seguiría funcionando y podríamos demostrar por qué se tomaron las decisiones? Esa respuesta suele revelar el nivel real de institucionalización.

Evidencia mínima

Qué conservaría para poder demostrar que el control está vivo

La cantidad de documentación no es una medida de madurez. Para «¿Sabe el comité de dirección qué es un SGCN?» prefiero una cadena corta de evidencias conectadas a la operación. Cada pieza debe responder a una pregunta distinta: qué decidimos, qué hicimos, qué ocurrió y qué revisamos después.

La siguiente matriz es el paquete mínimo que intentaría localizar en una revisión. El formato puede ser un acta, un ticket, una exportación, una configuración o un registro de una herramienta; lo importante es la trazabilidad y la coherencia entre las piezas.

Ref.EvidenciaQué debería demostrarQué revisaría
EV-01Alcance y propietarioQué cubre el control y quién responde por él.Vigencia, exclusiones, dependencias y aceptación del propietario.
EV-02Criterio de riesgoPor qué se ha priorizado o diseñado de una forma concreta.Información para decidir, escenario, impacto y supuestos utilizados.
EV-03Diseño del controlQué debe ocurrir, sobre qué población y con qué frecuencia.Riesgos y desviaciones relevantes, responsables, entradas, salidas y excepciones.
EV-04Muestra de ejecuciónQue el control opera fuera del documento.Fecha, población, resultado, anomalías y trazabilidad técnica u operativa.
EV-05Desviación y tratamientoCómo responde la organización cuando el control falla.Causa, riesgo residual, responsable, plazo y medida compensatoria.
EV-06Revisión y mejoraQue acuerdos, recursos y seguimiento se evalúa y puede cambiar.Indicadores, tendencia, decisiones, cambios aprobados y seguimiento.
Visión de auditor

Yo intentaría seguir una sola muestra de extremo a extremo. Si EV-01 dice una cosa, EV-03 otra y EV-04 no permite identificar la población afectada, el problema no es «falta de un PDF»: es una ruptura de trazabilidad.

Documentación operativa

Cómo convertir este tema en un expediente verificable

La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.

En ¿Sabe el comité de dirección qué es un SGCN?, el análisis debería cubrir al menos objetivos, riesgos, controles, responsables, evidencias, excepciones, indicadores y decisiones. Esto exige coordinar a Dirección, Riesgos, Seguridad, Auditoría, Compliance, Operaciones y propietarios de proceso y trabajar sobre objetivos, riesgos, controles, indicadores, incidencias, excepciones, evidencias y decisiones. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.

Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.

Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.

La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.

DimensiónQué debe quedar definidoEvidencia esperada
AlcanceProcesos, servicios, sistemas y terceros incluidos en «¿Sabe el comité de dirección qué es un SGCN?».Alcance aprobado, inventario y exclusiones justificadas.
ResponsabilidadQuién decide, ejecuta, valida y acepta desviaciones.RACI, actas, aprobaciones y propietarios nominativos.
OperaciónActividades repetibles, entradas, salidas, plazos y escalados.Procedimiento, tickets, registros, alertas y métricas.
EficaciaCómo se comprueba que el control cambia el riesgo o el resultado.Pruebas, tendencias, incidencias, muestreo y acciones.
Escenario de validación

Prueba de extremo a extremo

  1. Partir de una organización con varios marcos, herramientas separadas y responsabilidades repartidas y delimitar objetivos, riesgos, controles, responsables, evidencias, excepciones, indicadores y decisiones.
  2. Contrastar la documentación declarada con arquitectura, proceso, responsables y operación real.
  3. Seleccionar una muestra reciente y seguirla desde el evento de origen hasta su cierre.
  4. Distinguir entre fallo puntual, deficiencia de diseño y problema operativo recurrente.
  5. Verificar la corrección mediante una prueba posterior y no solo mediante una declaración de cierre.
Punto de control

Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.

Evidencias mínimas

Qué conservaría para una revisión seria

  • responsabilidades, registro de riesgos, catálogo de controles, indicadores, actas, pruebas y planes de mejora
  • criterio aplicado y versión de la referencia utilizada
  • población, periodo y muestra revisados
  • excepciones, aceptación de riesgo y fecha de caducidad
  • resultado de eficacia y acciones derivadas
Preguntas de contraste

Qué preguntaría antes de darlo por implantado

  • ¿Qué parte de «¿Sabe el comité de dirección qué es un SGCN?» está dentro del alcance y qué queda fuera?
  • ¿Quién aprueba una excepción, por qué y durante cuánto tiempo?
  • ¿Qué evidencia nace automáticamente de la operación y cuál se prepara manualmente?
  • ¿Cómo se detecta que el modelo de gobierno, la taxonomía común, el workflow de decisión, las métricas y el aseguramiento deja de funcionar?
  • ¿Cuál fue la última prueba que cambió una decisión, un diseño o una prioridad?
  • ¿Puede una persona ajena al proceso reconstruir el expediente sin explicaciones adicionales?

El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.

La continuidad empieza
con una conversación honesta.
No con un documento. Con la pregunta correcta en la reunión correcta.
Si este artículo ha generado alguna pregunta incómoda, es que está funcionando.
Sobre el autor
Miguel Ángel Carriazo · vCISO

vCISO · Arquitecto de Soluciones de Infraestructura y Ciberseguridad | Gobierno, Riesgo y Cumplimiento (GRC) | Gobierno de IA · ISO 42001 | Fundador de GRCreal

Compartir artículo