Presentación Liderazgo Ciberseguridad

La vulnerabilidad no es el riesgo: una presentación y un nuevo desafío

calendar_today 21 de septiembre de 2026

schedule 5 min de lectura

Mapa de dependencias y activos críticos — Fuente: Imagen conceptual generada con Inteligencia Artificial

He visto organizaciones con inventarios extensos de vulnerabilidades, tableros de severidad impecables y programas de remediación muy activos que, aun así, no podían responder una pregunta elemental: ¿qué proceso de negocio se detiene si falla este activo? La pregunta parece sencilla; responderla rara vez lo es.

Los capítulos 6, 8, 9 y 10 de Information Security Risk Management for ISO27001/ISO17799 de Calder y Watkins (2007) ofrecen una secuencia que sigue siendo útil: identificar lo que se debe proteger, entender las consecuencias de su pérdida, evaluar el riesgo y decidir cómo tratarlo. Mi experiencia me ha enseñado que el valor de esa secuencia no está en llenar una matriz. Está en obligarnos a pasar de la vulnerabilidad aislada a la conversación que el negocio sí puede decidir: operación, impacto, inversión y riesgo residual.

Desde la trinchera: el activo crítico casi nunca viene marcado como crítico

Uno de los errores más costosos que he encontrado es asumir que los activos importantes son evidentes. Es natural concentrarse en las plataformas visibles: el core bancario, el ERP, el portal de clientes. Sin embargo, los incidentes más incómodos suelen demostrar que la operación descansa también en sistemas satélite, integraciones, bases de datos, servicios de identidad, colas de mensajería, repositorios y componentes de red que reciben mucha menos atención.

En un entorno de crédito, por ejemplo, el core puede ser el corazón de la operación, pero no funciona en el vacío. La originación, la consulta de buró, la validación de identidad, el cálculo de capacidad de pago, la generación documental y las interfaces con terceros pueden ser dependencias indispensables. Si uno de esos componentes falla, está mal configurado o queda expuesto, el negocio puede dejar de otorgar crédito aunque el core esté disponible y sin una vulnerabilidad crítica conocida.

Ahí está la diferencia que más importa: un activo no es crítico por su tecnología, sino por el proceso, la información y las dependencias que habilita. Un servidor con una vulnerabilidad de alta severidad técnica puede tener una exposición manejable si no soporta un proceso relevante o si existen controles compensatorios. En cambio, una debilidad aparentemente moderada en un servicio satélite puede interrumpir una cadena de valor completa.

Por eso no empiezo una conversación de priorización con el escáner. Empiezo con un mapa: qué procesos son esenciales; qué aplicaciones los soportan; qué datos, personas, proveedores y componentes técnicos necesitan; y qué ocurre cuando cualquiera de ellos deja de cumplir su función. Este ejercicio revela relaciones que los inventarios tradicionales no muestran y evita que la organización confunda "activo registrado" con "activo entendido".

La aportación de Calder y Watkins es especialmente valiosa aquí. Su enfoque de evaluación orientada a los propietarios de activos dirige la atención a la relación entre activo, amenaza, vulnerabilidad, consecuencia y tratamiento. En la práctica, yo extendería esa mirada del activo individual al servicio completo. No basta saber que existe una aplicación; hay que saber qué proceso soporta, quién depende de ella, qué dependencia externa la condiciona y cuál sería el costo operativo, regulatorio y reputacional de perderla.

Este conocimiento también evita el sobrecontrol. Cuando no entendemos interdependencias ni criticidad, solemos responder con el mismo reflejo: endurecer todo, pedir más herramientas y multiplicar controles. El resultado puede ser un programa caro, complejo y difícil de operar que reduce poco el riesgo que de verdad preocupa al negocio. La disciplina no consiste en poner controles en cada hallazgo; consiste en elegir controles proporcionales a la exposición que se quiere reducir.

Del hallazgo técnico a una decisión de negocio

Para un líder de negocio, una vulnerabilidad no es todavía una decisión. Es un dato técnico. Se convierte en riesgo cuando puedo explicar qué escenario la haría relevante, con qué probabilidad razonable podría ocurrir, qué proceso afectaría, durante cuánto tiempo y cuáles serían las consecuencias para clientes, ingresos, continuidad, cumplimiento y reputación.

Esa traducción cambia la priorización. En lugar de ordenar el trabajo únicamente por una calificación de severidad, comparo riesgos considerando el impacto en el proceso, la factibilidad de explotación, los controles existentes, el costo de mitigar, los compromisos regulatorios y el riesgo residual. Una vulnerabilidad crítica sigue mereciendo atención urgente cuando expone una ruta real hacia un activo o servicio crítico. Pero una clasificación técnica, por sí sola, no puede decidir dónde invertir primero.

En mi experiencia, llevar la aceptación del riesgo al nivel de negocio es la única forma sostenible de avanzar. El dueño del proceso de negocio debe aceptar el riesgo residual porque es quien asume las consecuencias operativas si el escenario se materializa. El CISO no debe delegar esa conversación ni usar la aceptación como un trámite. Su responsabilidad es llegar con información clara y oportuna: el escenario de riesgo, la probabilidad, el impacto, los controles actuales, las alternativas de tratamiento, el costo de cada una y el nivel de exposición que permanecería.

Cuando la conversación está bien planteada, ocurre algo revelador: muchos tomadores de decisión prefieren financiar la mitigación antes que aceptar formalmente la responsabilidad de un incidente mayor. No es una táctica de presión; es el resultado natural de hacer visible la consecuencia que antes estaba oculta detrás de un identificador técnico. El presupuesto deja de ser una petición abstracta de seguridad y se vuelve una decisión sobre continuidad, apetito de riesgo y protección de un proceso que genera valor.

El tratamiento tampoco es sinónimo de mitigar. Dependiendo del impacto, el costo, la regulación y el apetito de riesgo, la organización puede evitar una actividad, transferir parte de la exposición, aceptar el riesgo de manera informada o implementar controles para reducirlo. La madurez se observa menos en la cantidad de controles desplegados que en la calidad de estas decisiones y en la claridad de quién las toma.

Un refuerzo contemporáneo, no una reinterpretación del libro

Los marcos publicados después de la obra de Calder y Watkins refuerzan esta lógica, pero no sustituyen su contexto original. ISO/IEC 27001:2022 mantiene el enfoque de un sistema de gestión basado en riesgos; NIST CSF 2.0 hace explícita la función Govern y vincula la gestión de activos con su importancia relativa para los objetivos organizacionales. NIST SP 800-30 Rev. 1, por su parte, articula la evaluación alrededor de amenazas, vulnerabilidades, probabilidad e impacto.

Leídos juntos, estos referentes sostienen una práctica sencilla de expresar y exigente de ejecutar: antes de preguntar cuántas vulnerabilidades cerramos, preguntemos qué riesgos de negocio reducimos. Para responderlo necesitamos un mapa vivo de activos y dependencias, criterios de impacto acordados con el negocio y una ruta de escalamiento que lleve el riesgo residual a quien tiene la autoridad para aceptarlo o financiar su reducción.

Mi regla de trabajo es ésta: la ciberseguridad debe comenzar entendiendo el negocio, no escaneando vulnerabilidades. El escáner es indispensable; el mapa de procesos, activos y dependencias es lo que permite interpretar sus resultados. Sin esa arquitectura de contexto, podemos trabajar mucho y proteger poco. Con ella, el CISO puede convertir hallazgos técnicos en decisiones que la organización entiende, prioriza y respalda.

Referencias

Calder, A., & Watkins, S. G. (2007). Information security risk management for ISO27001/ISO17799. IT Governance Publishing.
International Organization for Standardization. (2022). ISO/IEC 27001:2022: Information security, cybersecurity and privacy protection — Information security management systems — Requirements.
National Institute of Standards and Technology. (2024). The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29).
Ross, R. (2012). Guide for conducting risk assessments (NIST Special Publication 800-30 Rev. 1). National Institute of Standards and Technology.

I have seen organizations with extensive vulnerability inventories, impeccable severity dashboards, and highly active remediation programs that, even so, could not answer a basic question: what business process stops if this asset fails? The question seems simple; answering it rarely is.

Chapters 6, 8, 9, and 10 of Information Security Risk Management for ISO27001/ISO17799 by Calder and Watkins (2007) offer a sequence that remains useful: identify what must be protected, understand the consequences of its loss, assess the risk, and decide how to treat it. My experience has taught me that the value of this sequence lies not in filling out a matrix. It lies in forcing us to move from the isolated vulnerability to the conversation that the business can actually decide on: operation, impact, investment, and residual risk.

From the trenches: the critical asset rarely comes marked as critical

One of the most costly mistakes I have encountered is assuming that important assets are obvious. It is natural to focus on visible platforms: the core banking system, the ERP, the customer portal. However, the most uncomfortable incidents usually demonstrate that operations also rest on satellite systems, integrations, databases, identity services, messaging queues, repositories, and network components that receive much less attention.

In a credit environment, for example, the core might be the heart of the operation, but it doesn't function in a vacuum. Origination, bureau queries, identity validation, payment capacity calculation, document generation, and interfaces with third parties can be indispensable dependencies. If one of these components fails, is misconfigured, or is exposed, the business may stop granting credit even if the core is available and has no known critical vulnerabilities.

Therein lies the difference that matters most: an asset is not critical because of its technology, but because of the process, information, and dependencies it enables. A server with a vulnerability of high technical severity may have a manageable exposure if it does not support a relevant process or if compensating controls exist. In contrast, a seemingly moderate weakness in a satellite service can interrupt an entire value chain.

That is why I never start a prioritization conversation with the scanner. I start with a map: what processes are essential; what applications support them; what data, people, suppliers, and technical components they need; and what happens when any of them stops performing its function. This exercise reveals relationships that traditional inventories do not show and prevents the organization from confusing "registered asset" with "understood asset".

Calder and Watkins' contribution is especially valuable here. Their asset-owner-oriented evaluation approach directs attention to the relationship between asset, threat, vulnerability, consequence, and treatment. In practice, I would extend that view from the individual asset to the entire service. It is not enough to know that an application exists; we must know what process it supports, who depends on it, what external dependency conditions it, and what the operational, regulatory, and reputational cost of losing it would be.

This knowledge also prevents over-control. When we do not understand interdependencies or criticality, we tend to respond with the same reflex: harden everything, ask for more tools, and multiply controls. The result can be an expensive, complex program that is difficult to operate and does little to reduce the risk that the business actually cares about. Discipline does not consist of putting controls on every finding; it consists of choosing controls proportional to the exposure we want to reduce.

From a technical finding to a business decision

For a business leader, a vulnerability is not yet a decision. It is a technical fact. It becomes a risk when I can explain what scenario would make it relevant, with what reasonable probability it could occur, what process it would affect, for how long, and what the consequences would be for customers, revenue, continuity, compliance, and reputation.

That translation changes the prioritization. Instead of ordering work solely by a severity rating, I compare risks considering the impact on the process, the feasibility of exploitation, existing controls, the cost of mitigating, regulatory commitments, and residual risk. A critical vulnerability still deserves urgent attention when it exposes a real path to a critical asset or service. But a technical classification, by itself, cannot decide where to invest first.

In my experience, elevating risk acceptance to the business level is the only sustainable way forward. The business process owner must accept the residual risk because they are the one who assumes the operational consequences if the scenario materializes. The CISO should not delegate that conversation or use acceptance as a formality. Their responsibility is to arrive with clear and timely information: the risk scenario, probability, impact, current controls, treatment alternatives, the cost of each, and the level of exposure that would remain.

When the conversation is well framed, something revealing happens: many decision-makers prefer to fund mitigation rather than formally accept responsibility for a major incident. This is not a pressure tactic; it is the natural result of making visible the consequence that was previously hidden behind a technical identifier. The budget ceases to be an abstract security request and becomes a decision about continuity, risk appetite, and protecting a process that generates value.

Treatment is also not synonymous with mitigation. Depending on impact, cost, regulation, and risk appetite, the organization can avoid an activity, transfer part of the exposure, make an informed acceptance of the risk, or implement controls to reduce it. Maturity is seen less in the number of controls deployed than in the quality of these decisions and the clarity of who makes them.

A contemporary reinforcement, not a reinterpretation of the book

Frameworks published after Calder and Watkins' work reinforce this logic, but do not replace its original context. ISO/IEC 27001:2022 maintains the focus on a risk-based management system; NIST CSF 2.0 makes the Govern function explicit and links asset management to its relative importance for organizational objectives. NIST SP 800-30 Rev. 1, for its part, articulates the assessment around threats, vulnerabilities, likelihood, and impact.

Read together, these benchmarks support a practice that is simple to express and demanding to execute: before asking how many vulnerabilities we closed, let's ask what business risks we reduced. To answer this, we need a living map of assets and dependencies, impact criteria agreed upon with the business, and an escalation path that takes residual risk to those with the authority to accept it or fund its reduction.

My working rule is this: cybersecurity must begin by understanding the business, not by scanning for vulnerabilities. The scanner is indispensable; the map of processes, assets, and dependencies is what allows us to interpret its results. Without that architectural context, we can work a lot and protect a little. With it, the CISO can turn technical findings into decisions that the organization understands, prioritizes, and supports.

References

Calder, A., & Watkins, S. G. (2007). Information security risk management for ISO27001/ISO17799. IT Governance Publishing.
International Organization for Standardization. (2022). ISO/IEC 27001:2022: Information security, cybersecurity and privacy protection — Information security management systems — Requirements.
National Institute of Standards and Technology. (2024). The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29).
Ross, R. (2012). Guide for conducting risk assessments (NIST Special Publication 800-30 Rev. 1). National Institute of Standards and Technology.

Comentarios

arrow_back Volver a publicaciones