Un escenario de riesgo cibernético explica cómo una situación puede producir una consecuencia para la organización. «Ransomware», «proveedor» o «falta de formación» son etiquetas útiles para iniciar una conversación, pero no describen por sí solas una cadena de hechos que pueda evaluarse y tratarse. La ficha debe unir desencadenante, activo, evento, impacto y límites del conocimiento.
El resultado propuesto es un esquema repetible con un ejemplo desarrollado. Se apoya en el contexto de integración del riesgo que ofrece NIST SP 1303 y en el Cybersecurity Framework, comprobados de nuevo el 27 de septiembre de 2026. Las escalas y decisiones que se presentan son propuestas internas, no valores oficiales de probabilidad.
Empezar por una actividad que importe
Identifique una operación concreta: aceptar pedidos, emitir pagos, atender pacientes, mantener una planta o responder a clientes. Describa el resultado que debe preservarse y quién conoce sus condiciones de funcionamiento. Así evita redactar escenarios que terminan en «pérdida de seguridad» sin explicar la consecuencia práctica.
Seleccione después los activos y dependencias necesarios para esa operación. Un activo puede ser información, una aplicación, una identidad, infraestructura o un servicio externo. La lista debe permitir seguir la cadena del escenario, sin convertirse en un inventario exhaustivo de todo el departamento.
La gestión de proveedores TIC ayuda a conectar una dependencia externa con la función apoyada. Cuando DORA no resulte aplicable, esa relación sigue siendo útil como análisis operativo, pero no debe presentarse como una obligación específica derivada de ese reglamento.
Elegir el límite del escenario antes de valorarlo
Un escenario demasiado amplio mezcla causas que necesitan medidas distintas. «Ataque al portal» puede reunir robo de credenciales, error de configuración, interrupción del proveedor y modificación maliciosa de documentos. Separe esas secuencias cuando cambien los controles, la probabilidad razonada o la persona capaz de decidir el tratamiento. En cambio, no genere una ficha nueva para cada servidor si todos comparten el mismo mecanismo y consecuencia. El límite debe servir a una decisión identificable.
En el ejemplo del portal, puede analizar por separado la modificación de rutas mediante una cuenta de soporte y la indisponibilidad completa del proveedor. El primer escenario requiere revisar privilegios y alertas; el segundo exige entender continuidad, alternativas de trabajo y dependencia contractual. Aunque ambos afecten a la entrega de documentos, reunirlos bajo una sola puntuación ocultaría acciones diferentes. Escriba en cada ficha qué sistemas, periodos y operaciones comprende, y qué queda fuera.
Incluya a los participantes que conocen esas fronteras. El equipo técnico sabe si la cuenta puede cambiar rutas; el negocio sabe si la entrega manual es viable; el proveedor conoce los límites de su servicio. Si falta una de esas perspectivas, registre la laguna en vez de asumirla. La guía NIST SP 800-30 estructura la evaluación alrededor de preparación, análisis y mantenimiento: delimitar el objeto antes de asignar valores es una aplicación práctica de esa secuencia.
Distinguir los componentes de la ficha
| Componente | Pregunta | Ejemplo hipotético |
|---|---|---|
| Desencadenante | ¿Qué inicia la secuencia? | Una credencial de soporte queda comprometida |
| Activo | ¿Sobre qué recurso puede actuar? | Consola de administración del portal |
| Condición | ¿Qué permite que progrese? | Permisos amplios y ausencia de restricción adecuada |
| Evento | ¿Qué ocurre en el sistema? | Se modifican rutas de entrega de documentos |
| Consecuencia | ¿Qué efecto produce en la actividad? | Envíos incorrectos y suspensión del servicio |
| Controles | ¿Qué previene, detecta o limita el hecho? | Acceso limitado, revisión y alertas |
| Incertidumbre | ¿Qué no se conoce suficientemente? | Alcance real de ciertos permisos heredados |
| Decisión | ¿Qué actuación cambia la exposición? | Reducir permisos y verificar su efecto |
No todos los escenarios requieren un atacante. Un error de configuración, una interrupción de infraestructura o una dependencia no disponible pueden iniciar secuencias relevantes. La ficha debe identificar el mecanismo, en vez de forzar todas las situaciones dentro de una narración de ataque.
Escribir una frase causal y después comprobarla
Una formulación inicial puede ser: «Si una credencial de soporte comprometida permite modificar la configuración del portal, podrían enviarse documentos al destino equivocado y suspenderse la operación mientras se verifica su integridad». Esta frase une posibilidad técnica y consecuencia de negocio, pero todavía contiene hipótesis.
El equipo técnico debe comprobar qué permite realmente la credencial. El responsable del proceso debe explicar qué operaciones dependen de la configuración. Seguridad debe identificar controles existentes y pruebas disponibles. Si una conexión no puede justificarse, la ficha debe marcarla como hipótesis o cambiar el escenario.
La metodología de auditoría ayuda a distinguir declaración y evidencia. No se necesita una prueba destructiva para cada escenario, pero sí una explicación razonable de por qué la cadena es posible en el entorno analizado.
Aclarar la incertidumbre antes de valorar
Es útil distinguir un hecho comprobado, una estimación razonada y una hipótesis pendiente. «La cuenta puede modificar rutas» puede acreditarse mediante una revisión de permisos. «Un atacante conseguiría esa cuenta» requiere otras evidencias y juicio. «La operación se recuperaría en un día» depende de personal, volumen y pruebas de continuidad. Anote junto a cada afirmación su fuente, fecha y grado de confianza, utilizando criterios propios explícitos.
Cuando falta información, describa cómo podría cambiar la decisión. Si el supuesto de acceso privilegiado resulta falso, el escenario puede reducirse o reformularse. Si resulta que los cambios no dejan registro, la detección sería más débil de lo pensado. Esta sensibilidad es más útil que añadir decimales a una escala cualitativa. También orienta una comprobación concreta: revisar permisos heredados, ejecutar un ejercicio de continuidad o pedir al proveedor un detalle técnico.
La publicación NIST SP 800-30 aborda fuentes de amenaza, vulnerabilidades, probabilidad, impacto e incertidumbre. No proporciona una probabilidad universal para el portal hipotético de esta guía. Documente la razón de la valoración con las condiciones observadas localmente; si una amenaza pública se cita como contexto, compruebe que la tecnología y el modo de uso corresponden al entorno real.
Desarrollar el ejemplo sin fingir una estimación exacta
Una empresa ficticia intercambia documentación contractual mediante un portal. El soporte externo dispone de acceso a ciertas configuraciones. La organización quiere evaluar el riesgo de que una cuenta comprometida cambie el destino de entrega de los documentos.
La revisión confirma que el soporte puede modificar rutas, pero no descargar directamente todos los documentos. También descubre que los cambios generan un registro que nadie revisa de forma habitual. El escenario se ajusta: la consecuencia no parte de una capacidad genérica de administrador, sino de una función concreta que puede redirigir entregas futuras.
El negocio estima que suspender el portal durante un día obligaría a usar un procedimiento manual con capacidad limitada. Esta estimación se documenta con sus supuestos: volumen esperado, personal disponible y documentos pendientes. No se transforma en una cifra monetaria precisa sin datos adicionales.
Las medidas propuestas son limitar el cambio de rutas, exigir una aprobación adecuada y revisar alertas de modificación. La organización prueba una configuración permitida y otra que debe ser rechazada. Después verifica que la alerta llega a una persona con capacidad de actuar. El riesgo residual conserva el supuesto de que otras vías de compromiso todavía podrían existir.
Separar riesgo inherente, controles y riesgo residual
Si utiliza estas categorías, defina qué significa cada una en su método. El riesgo inherente puede describir la situación sin considerar determinados controles; el residual incorpora los controles evaluados. Evite comparar cifras si cada equipo está usando una base distinta.
No reduzca el riesgo porque una política exista en un repositorio. Determine qué actividad implementa el control y qué prueba demuestra su funcionamiento. La relación entre ISO 27001 y RGPD muestra por qué documentar un sistema y evaluar efectos concretos son tareas relacionadas pero diferentes.
Distinga también controles previstos de controles operativos. Una compra aprobada o una acción en curso no justifica describir la exposición actual como si la mejora ya estuviera funcionando. Puede registrar una estimación futura, identificada como tal y condicionada a una verificación.
Usar escalas que ayuden a decidir
Una escala cualitativa puede ser suficiente si sus niveles tienen definiciones comprensibles. Para impacto, describa interrupción, pérdida de información, capacidad de recuperación y consecuencias pertinentes. Para probabilidad, explique qué observaciones y condiciones sustentan la valoración, así como su incertidumbre.
No multiplique números ordinales como si fueran probabilidades medidas sin explicar las limitaciones. Una matriz puede ordenar conversaciones, pero dos escenarios con la misma casilla pueden requerir tratamientos muy distintos. Conserve la narración y las pruebas junto al valor resumido.
El ENS puede imponer un contexto específico cuando sea aplicable. La ficha debe ajustarse a la metodología adoptada por la organización y a sus exigencias, sin afirmar que una tabla genérica cumple automáticamente cualquier marco.
Comparar tratamientos por el punto de la cadena que modifican
Una medida preventiva puede reducir la posibilidad del evento. Una medida de detección puede acortar el tiempo hasta la respuesta. Una capacidad de recuperación puede limitar la duración de la interrupción. Escriba qué parte cambia cada acción y qué evidencia confirmaría ese cambio.
En el ejemplo hipotético, formar al soporte no sustituye una restricción de permisos excesivos. Esta precisión permite combinar medidas sin contarlas como si todas produjeran el mismo efecto.
Suponga, de forma hipotética, que el equipo propone exigir una segunda aprobación para modificar rutas y, en paralelo, configurar alertas. La aprobación puede dificultar un cambio no autorizado, pero su valor depende de que el segundo aprobador vea el destino nuevo y pueda rechazarlo. La alerta puede acortar el tiempo de respuesta, pero debe llegar a alguien que la atienda fuera del horario habitual. En la ficha, describa qué tramo de la cadena modifica cada medida y qué prueba demostraría su funcionamiento.
Compare después el esfuerzo y los efectos secundarios. Una doble aprobación podría retrasar una corrección legítima urgente; una alerta demasiado frecuente podría perderse entre avisos irrelevantes. El dueño del proceso debe decidir qué combinación conserva la capacidad operativa requerida. Una prueba con cambios permitidos y denegados, seguida de una revisión de recepción de alertas, da más información que marcar ambas medidas como «implementadas» por aparecer en un plan.
Para dependencias externas, el procedimiento de comunicación de vulnerabilidades puede ser una pieza del tratamiento. Debe demostrarse que el canal y los responsables funcionan, no únicamente que existe una cláusula en el contrato.
Registrar aceptación y revisión
La persona con autoridad decide entre tratar, evitar, transferir determinados efectos o aceptar el riesgo según el marco interno. La aceptación debe identificar escenario, condiciones, medidas pendientes y razones. Un estado «aceptado» sin nombre ni contexto no permite entender quién asumió la decisión.
Si se acepta temporalmente el riesgo mientras se despliega una medida, indique la exposición actual, el responsable y el hecho que cerrará esa aceptación. Evite escribir «riesgo residual bajo» antes de comprobar el control. La guía NIST SP 1303 sitúa la información de ciberseguridad en un proceso más amplio de gestión del riesgo; el intercambio con quien decide sobre la actividad es parte práctica de esa integración.
Establezca eventos que obliguen a revisar: nuevas funciones, cambios de permisos, incidente, proveedor diferente o evidencia que contradiga un supuesto. Una fecha periódica puede complementar esos eventos, pero no debe retrasar el examen de un cambio importante ya conocido.
Conserve versiones anteriores. Si la valoración cambia porque aparece información nueva, explique la diferencia. El registro histórico permite aprender de las hipótesis que resultaron débiles sin reescribir retrospectivamente lo que el equipo sabía.
Convertir una ficha en decisiones para otras áreas
Una ficha útil tiene salidas distintas para cada propietario. Seguridad recibe la condición técnica que debe verificar. Operación conoce qué registro o alerta vigilar. El responsable de continuidad sabe qué alternativa activar si el servicio se suspende. Compras puede pedir al proveedor información sobre privilegios o recuperación, pero no debe convertir una afirmación comercial en evidencia técnica sin contrastarla. Cada salida conserva un vínculo con el mismo escenario para evitar versiones contradictorias.
Cuando una medida se entrega, actualice la ficha con la fecha y el resultado de su comprobación. Si la alerta nunca llegó al equipo de guardia, la instalación del software no justifica reducir la valoración. Si el trabajo manual soportó menos volumen del previsto en un ensayo, revise el impacto de indisponibilidad. Un escenario no es un documento congelado: su utilidad depende de que la decisión refleje las condiciones que efectivamente existen.
Finalmente, prepare un resumen para quien acepta el riesgo: secuencia causal en una frase, consecuencia operativa, controles comprobados, incertidumbres que podrían cambiar la conclusión y decisión solicitada. Mantenga detrás el detalle técnico y las referencias. Ese resumen permite discutir prioridades entre áreas sin perder la trazabilidad. También deja visible por qué dos fichas con una etiqueta similar pueden necesitar inversiones o respuestas distintas.
Comprobar la calidad de la ficha
Pida a una persona ajena al taller que identifique qué inicia el escenario, qué activo interviene, cómo se produce el evento y qué decisión se propone. Si necesita inventar conexiones para entenderlo, la ficha requiere una revisión.
La gestión de incidentes y brechas puede aportar hechos para mejorar escenarios posteriores, manteniendo separadas predicción y observación. Una ficha útil no promete que todo ocurrirá exactamente como se ha descrito. Proporciona una base razonada para actuar, comprobar las medidas y revisar la decisión cuando cambian los hechos.