Vigilancia

Qué exige, en claro

Mantener una vigilancia continua del sistema: los eventos de seguridad (registros de op.exp.8, alertas de op.mon.1) se recopilan y analizan de forma sistemática para conocer en todo momento el estado de seguridad, con medios propios o de un tercero (SOC).

Incorporar inteligencia de amenazas: avisos y campañas publicados por el CCN-CERT y fuentes equivalentes, vulnerabilidades que afectan a tus componentes, y la consiguiente reevaluación de riesgos y prioridades cuando aparece una amenaza relevante.

Cuándo aplica y cómo escala

Aplica con carácter general: la profundidad de la vigilancia (de revisar avisos y alertas con disciplina a un SOC con correlación continua) crece con la categoría. Confírmalo en la valoración formal del sistema.

Ejemplos de implementación

• Suscripción a los avisos del CCN-CERT y del proveedor cloud, revisión diaria breve de alertas y panel de vulnerabilidades de los componentes propios, con criterio escrito de cuándo se actúa de urgencia.
• Servicio SOC 24×7 (propio o contratado) que correlaciona registros del sistema, notifica según severidad y emite informe mensual del estado de seguridad al responsable.

Errores habituales

• Vigilar solo cuando algo ya ha fallado: la vigilancia es rutina, no reacción.
• Ignorar los avisos públicos de campañas activas que afectan justo a tu software.
• Recopilar eventos que nadie correlaciona ni mira: almacenamiento, no vigilancia.
• No reevaluar el riesgo tras un cambio grande del panorama (una vulnerabilidad crítica en tu stack).
• Contratar un SOC y no definir quién recibe sus avisos ni qué hace con ellos.

Evidencias que suele ser razonable preparar

• Descripción del dispositivo de vigilancia: fuentes de eventos, herramientas, responsables, horario.
• Fuentes de inteligencia de amenazas utilizadas y registro de avisos relevantes tratados.
• Informes periódicos del estado de seguridad del sistema.
• Reevaluaciones de riesgo motivadas por amenazas o vulnerabilidades sobrevenidas.

Preguntas que debería hacerse el responsable

• ¿Quién sabe, hoy, cuál es el estado de seguridad de tu sistema — y con qué datos?
• ¿Cómo te enteras de que hay una campaña activa contra el software que usas?
• ¿Qué vulnerabilidad crítica de tu stack se publicó este mes y qué hiciste?
• Si tu vigilancia la presta un tercero, ¿qué recibes de él y quién lo lee?

Fuente oficial: Anexo II del Real Decreto 311/2022 y Guía CCN-STIC 817 · Gestión de ciberincidentes (CCN-CERT). Ficha elaborada por Roberto Mickel, fundador y CTO de ENSFácil; revisada el 25 de agosto de 2026: la aplicabilidad exacta y los refuerzos dependen de la categoría y valoración de tu sistema — verifica siempre la versión vigente de la norma y de las guías.