Era una fecha de alto movimiento económico en un banco de la región. La app de banca en línea estaba “encendida”: la pantalla cargaba, los menús respondían, el cliente podía iniciar una transacción. Pero al confirmar el pago, no pasaba nada. La operación se quedaba colgada y el dinero no salía. Por fuera, el sistema funcionaba. Por dentro, no completaba lo que importaba. Cada episodio así duraba entre tres y seis horas.
Mi rol en ese banco era técnico: investigaba incidentes y emitía los informes con el respaldo correspondiente. Cuando esto pasaba, me tocaba reconstruir qué había fallado. La causa raíz no era exótica: el dimensionamiento de los recursos en los sistemas críticos no alcanzaba para el volumen de transacciones de esos días de alto movimiento. Y ese volumen era previsible: figuraba en el calendario que cualquiera del negocio podía mirar. La capacidad no estaba ajustada a la demanda esperada.
Lo más doloroso no fue la primera caída. Fue la segunda, parecida a la primera, meses después. Tuve que escribir el segundo informe abriendo con una referencia al anterior, marcándolo como reincidencia. Y la tercera. Y la siguiente. Emitía el informe, asignaba al responsable, pactaba el plazo y hacía las gestiones de seguimiento para que se atendiera. Pero el cumplimiento del plan de tratamiento dependía de que otros lo ejecutaran, y siguió pasando hasta que dejé el banco. Sin final feliz.
Esa experiencia me dejó una de las lecciones más útiles de mi carrera: el informe técnico, la asignación del dueño y el plazo pactado son solo la mitad del trabajo. La otra mitad — la que de verdad cierra el riesgo — es que la organización entera sostenga la exigencia del cumplimiento, incluso cuando lo cómodo sería dejar correr el plazo. Sin esa segunda mitad, el plan de tratamiento existe en papel y el riesgo sigue abierto. Un incidente recurrente no es uno nuevo cada vez; es el mismo riesgo abierto, contando los meses.
Y ese, en el fondo, es el tema de hoy. Los datos del cliente estaban perfectamente a salvo y eran perfectamente correctos. Y aun así, en el momento que importaba, el banco le fallaba.
Eso tiene un nombre técnico: falla de Disponibilidad. El pilar más invisible de los tres y, casi siempre, el peor atendido.
En los dos artículos anteriores de esta serie recorrimos los dos primeros pilares de la Tríada CIA: la Confidencialidad, que protege lo que nadie debe ver, y la Integridad, que evita que el dato mienta. Hoy cerramos el arco con la tercera letra, la que sostiene a las otras dos:
La información puede estar perfectamente protegida y ser perfectamente correcta. Pero si no está ahí cuando se la necesita, las otras dos no sirvieron de nada.
¿Qué es realmente la Disponibilidad?
Si tuviera que definirla en una línea: la información correcta, accesible para quien tiene derecho a usarla, en el tiempo que el negocio tolera.
Fijate que esa definición tiene tres partes y ninguna sobra. No alcanza con que “el servidor esté encendido”. El servidor puede estar encendido y la base de datos corrupta. El sistema puede responder, pero tan lento que para el cliente es como si no respondiera. El servicio puede estar arriba para unos y caído para otros. Disponibilidad es que el dato o el servicio correcto llegue a quien corresponde dentro de la ventana de tiempo que la operación aguanta sin romperse.
Y acá está el cierre de la serie, planteado desde el principio: de nada sirve un dato confidencial e íntegro si llega tarde o no llega. La Disponibilidad es la que convierte la seguridad en valor de negocio. Sin ella, las otras dos son teóricas. Es la habilitación del negocio digital en estado puro: el cliente no ve tu cifrado ni tus controles de integridad, pero ve la app funcionando un viernes a fin de mes. O no la ve.
El riesgo oculto: la disponibilidad se da por sentada
Hay un sesgo que se repite en casi toda organización con la que uno conversa. La Confidencialidad y la Integridad se sienten como seguridad. Suenan a candado, a control, a auditoría. La Disponibilidad, en cambio, se confunde con “tema de infraestructura” y se delega hacia abajo hasta que un día falla y de golpe es tema de todos.
El resultado es una asignación desbalanceada del esfuerzo. Invertimos en evitar la brecha (el robo de datos, el titular vergonzoso) y subinvertimos en evitar la caída. Lo curioso es que la caída es más frecuente y más visible para el cliente que la brecha. Una fuga de datos puede tardar meses en conocerse; una indisponibilidad la nota el cliente en el segundo exacto en que la ruedita no para de girar.
¿Por qué pasa esto, una y otra vez, en organizaciones que en lo demás son serias?
Primero, porque se trata como problema técnico y no de negocio. La palabra “continuidad” suena a sala de servidores, no a ingreso por facturación perdido. Segundo, porque el respaldo da una falsa tranquilidad enorme: “tenemos backups” se confunde con “podemos restaurar a tiempo”, y no es lo mismo. Tercero, porque los puntos únicos de falla son invisibles hasta el día que caen (una persona que es la única que sabe operar cierto sistema, un proveedor del que dependemos sin haberlo mapeado, un componente sin reemplazo). Y cuarto, porque casi nadie ensaya la caída: el plan de continuidad existe en un PDF que se firmó hace dos años y nunca se probó bajo presión real.
Las formas en que la Disponibilidad se cae (y casi ninguna es un hacker)
Cuando uno piensa en seguridad, piensa en un atacante. Pero la mayoría de las caídas que dejan a un cliente sin servicio no las provoca un hacker: las provoca la fragilidad operativa propia. Estas son las formas más comunes en que un servicio se cae sin que nadie lo ataque:
El punto único de falla. Un componente, un proveedor o una persona de la que todo depende y que no tiene respaldo. El día que ese único nodo falla, falla todo lo que colgaba de él.
El backup que nunca se restauró de prueba. Se hacen copias todos los días, religiosamente. Pero nadie verificó nunca que esas copias se puedan restaurar de verdad, en cuánto tiempo y sin pérdida. El backup que no se probó es una hipótesis, no una garantía.
La dependencia de tercero no mapeada. El servicio de un proveedor cae y arrastra al tuyo, y recién ahí descubrís que dependías de él para algo crítico. Es la cara de disponibilidad del riesgo de proveedores: no controlás su operación, pero heredás su caída.
El cambio mal coordinado. Un despliegue, un parche o una actualización sin ventana definida y sin plan de marcha atrás que tumba producción. Una porción enorme de las caídas no las causa un enemigo externo, sino un cambio propio hecho a las apuradas.
La saturación por falta de capacidad. El pico de demanda —la campaña, el cierre de mes, el evento— que el sistema no aguanta. No hubo ataque: hubo éxito mal dimensionado.
Y sí, también el ataque: ransomware y DDoS. Vale nombrarlos, porque son los vectores que no buscan robar el dato sino secuestrarlo o tapar el servicio. El ransomware es, antes que nada, un ataque a la disponibilidad: cifra tu información y te deja sin acceso a ella. El DDoS satura el servicio hasta que nadie legítimo puede usarlo. Pero observá el orden de esta lista: el atacante aparece al final, no al principio. Empezar la casa por el ransomware y olvidar el cambio mal coordinado es proteger la puerta blindada mientras la ventana queda abierta.
Cómo proteger la Disponibilidad de verdad
Definí cuánto podés tolerar: RTO y RPO
No se protege lo que no se ha cuantificado. Antes de comprar tecnología o redactar planes, hay dos números que toda organización debería tener claros para sus servicios críticos.
El RTO (objetivo de tiempo de recuperación) responde a: ¿cuánto tiempo puede estar caído este servicio antes de que el daño sea grave? El RPO (objetivo de punto de recuperación) responde a: ¿cuánta información podemos permitirnos perder, medida en tiempo? Si el último respaldo bueno es de hace seis horas y el sistema cae, perdiste seis horas de operación.
Definir RTO y RPO es traducir “qué tan crítico es esto” a un número accionable. Y obliga a una conversación de negocio incómoda pero necesaria: cuánto cuesta achicar ese número. Bajar el RTO de cuatro horas a quince minutos no es gratis, y esa decisión no es técnica, es de negocio.
Backups con la regla 3-2-1 — y restauraciones probadas
La regla clásica sigue vigente: tres copias de la información, en dos tipos de medio distintos, con una fuera de sitio. Pero el corazón de esta sección no es la copia, es la restauración. El backup se mide por la capacidad de volver, no por la cantidad de copias guardadas.
Ensayar restauraciones de forma periódica es lo que separa “tenemos respaldos” de “podemos recuperarnos”. Y es justo el ejercicio que más se posterga, porque consume tiempo y nadie lo extraña hasta el día que lo necesita y descubre que la copia estaba incompleta o tardaba doce horas en levantar.
Redundancia y eliminación de puntos únicos de falla
Mapear los puntos únicos de falla —técnicos y humanos— y darles respaldo. Redundancia para los componentes críticos, sí, pero también para el conocimiento: si una sola persona sabe operar el sistema que sostiene la facturación, esa persona es un punto único de falla con vacaciones pendientes. La redundancia que no se probó con un failover real es, otra vez, una hipótesis.
Plan de continuidad y de recuperación — ensayados
El plan que no se ensaya no existe. Tener un BCP (plan de continuidad del negocio) y un DRP (plan de recuperación ante desastres) en un documento es el punto de partida, no la meta. La diferencia entre un PDF y una capacidad real de respuesta se mide en simulacros: apagar a propósito, en un entorno controlado, y ver si el equipo sabe qué hacer cuando el reloj corre y el cliente reclama.
Monitoreo de capacidad y salud del servicio
Anticipar la caída por saturación antes de que ocurra. Vigilar el uso de recursos para escalar a tiempo es lo que evita que el éxito de una campaña se transforme en una caída. Acá hay un puente fino con algo que ya conversamos: un servicio puede estar degradándose en silencio, sin alarma, hasta que cruza el umbral. La ausencia de ruido no es señal de salud; muchas veces es ausencia de visibilidad.
Disponibilidad e ISO 27001:2022
La norma no trata la disponibilidad como una idea abstracta: la aterriza en controles concretos del Anexo A. Estos cinco son los que más directamente la sostienen (traducción propia y fiel del texto normativo en inglés de la ISO/IEC 27001:2022):
A.5.29 — Seguridad de la información durante la disrupción. La organización debe planificar cómo mantener la seguridad de la información en un nivel apropiado durante una disrupción. Es decir: cuando todo se cae, los controles no deben caerse con todo lo demás.
A.5.30 — Preparación de las TIC para la continuidad del negocio. La preparación de las TIC debe planificarse, implementarse, mantenerse y probarse con base en los objetivos de continuidad del negocio. Es un control nuevo de la versión 2022, y no es casual: la norma incorporó explícitamente la palabra “probarse”. El plan en el papel ya no alcanza.
A.8.13 — Respaldo de la información. Las copias de respaldo de información, software y sistemas deben mantenerse y probarse con regularidad conforme a la política específica de respaldo. Otra vez la norma escribe “probarse”: el respaldo sin restauración verificada no cumple el control.
A.8.14 — Redundancia de las instalaciones de procesamiento de información. Las instalaciones deben implementarse con redundancia suficiente para cumplir los requisitos de disponibilidad. La redundancia se dimensiona contra un requisito, no “por las dudas”.
A.8.6 — Gestión de la capacidad. El uso de los recursos debe monitorearse y ajustarse en línea con los requisitos de capacidad actuales y previstos. La caída por saturación tiene un control con nombre y apellido.
Lo interesante no es el catálogo, es el patrón: cada control responde a una de las formas de caerse que vimos antes. La norma no inventa burocracia; ordena lo que la experiencia operativa ya enseñó a los golpes.
La moto: la mejor máquina no sirve si no arranca el día que la necesitás
En el artículo de Confidencialidad la metáfora fue el casco: protección sin excepciones, te lo ponés siempre. La Disponibilidad es otra cosa.
Podés tener la mejor moto, con la mayor potencia, impecable de papeles. Pero si el día que tenés que salir no arranca, toda esa potencia vale cero. Y si arranca pero te deja varado a mitad de ruta, sin kit de pinchazos, sin reserva de combustible, sin haber mirado las rutas alternas, la potencia tampoco te trajo de vuelta.
Salir a rodar lejos no depende solo de la máquina: depende de haber preparado la vuelta. Eso es la Disponibilidad. No es tener el sistema; es poder contar con él cuando importa. La libertad de salir tranquilo se construye antes de arrancar, con la previsión aburrida que nadie nota hasta el día que se pincha en el medio de la nada. Vivir libre, en seguridad, es exactamente eso: la confianza de que cuando lo necesites, va a estar.
Disponibilidad como riesgo de negocio
Hasta acá hablamos en lenguaje técnico. Pero para cualquier organización, y para todo líder de negocio, la disponibilidad se traduce en tres riesgos muy concretos.
El primero es operativo: una caída detiene la operación y la facturación al instante. No hay un período de gracia. El reloj que corre durante una indisponibilidad es, literalmente, dinero que no entra y operación que no avanza.
El segundo es reputacional: la disponibilidad es la cara pública de la seguridad. “El banco cuyo app no funciona” se vuelve titular, captura de pantalla y comentario en redes en cuestión de minutos. El cliente nunca va a aplaudir tu cifrado, pero sí va a contar a quien lo quiera escuchar el día que no pudo pagar.
El tercero es regulatorio: en banca y servicios financieros de la región, la continuidad operativa y el reporte de indisponibilidad no son opcionales, son exigencia del supervisor. Una caída prolongada no solo cuesta clientes; abre expediente.
La pregunta correcta para cualquier mesa de decisión es más incómoda que “¿estamos seguros?”, y bastante más útil: ¿sabemos cuánto tiempo podemos estar caídos antes de que el daño sea irreversible, y lo hemos probado de verdad?
Checklist rápido: ¿cómo está tu organización?
Si querés llevarte algo accionable de este artículo, recorré esta lista pensando en tus servicios críticos:
☐ ¿Están definidos el RTO y el RPO para los servicios críticos?
☐ ¿Se prueban las restauraciones de backup periódicamente, y no solo se hacen las copias?
☐ ¿Se han identificado y documentado los puntos únicos de falla, técnicos y humanos?
☐ ¿Existe redundancia real para los componentes más críticos, con failover probado?
☐ ¿Hay un BCP/DRP y se ha ensayado con simulacros, no solo escrito?
☐ ¿Se mapean las dependencias de terceros y su impacto en tu disponibilidad?
☐ ¿Se monitorea la capacidad para anticipar caídas por saturación?
☐ ¿La organización trata la continuidad como riesgo de negocio y no solo como tema técnico?
Cada “no” de esa lista es una hipótesis sin probar esperando el peor momento para revelarse.
Cierre de la trilogía
Con esto cerramos la serie. Y vale releerla como un solo argumento, no como tres piezas sueltas.
Confidencialidad: que no lo vea quien no debe. Integridad: que el dato no mienta. Disponibilidad: que esté cuando se lo necesita. Los tres no se reparten el presupuesto como objetivos separados: funcionan como uno solo, y fallar en cualquiera anula a los otros dos. Un dato secreto, correcto e inaccesible no sirve. Un dato disponible y correcto pero filtrado, tampoco. Un dato disponible y secreto pero adulterado, menos todavía.
La promesa con la que abrí esta serie era explicar la Tríada CIA como nadie te la explicó: sin jerga, sin fórmulas, traducida a decisiones de negocio. Si después de estos tres artículos mirás la app del banco un viernes a fin de mes y entendés que detrás de esa ruedita girando hay un pilar de seguridad mal atendido, la serie cumplió.
¿Cuál de los tres pilares está peor cuidado en tu organización? Te leo en los comentarios.
Vive libre, vive seguro.
#ViveLibreViveSeguro