Durante mucho tiempo, la ciberseguridad se explicó principalmente desde la prevención: evitar accesos indebidos, proteger información, cerrar vulnerabilidades, endurecer infraestructura, controlar identidades y reducir superficie de ataque.
Todo eso sigue siendo indispensable. Pero en banca digital ya no basta con pensar la seguridad solo como prevención. Las instituciones financieras operan en entornos distribuidos, integrados, automatizados, dependientes de terceros, expuestos por APIs y presionados por fraude, abuso automatizado e incidentes digitales.
En ese contexto, el Chief Information Security Officer (CISO) no puede ser visto solo como quien evita que algo malo ocurra. También debe ayudar a que la organización pueda detectar, responder, recuperar y aprender cuando algo falla.
La idea de fondo es simple: la confianza operativa no se construye prometiendo que nunca habrá incidentes; se diseña para resistirlos, contenerlos, explicarlos y aprender.
¿Cómo se relacionan CISO, arquitectura y resiliencia operativa en banca digital?#
El CISO, arquitectura y resiliencia operativa se relacionan porque la confianza digital no depende solo de controles preventivos. En banca digital, también exige capacidades de detección, respuesta, recuperación, observabilidad, continuidad, gestión de terceros, evidencia y aprendizaje. El CISO aporta visión de riesgo; arquitectura diseña capacidades sostenibles; operación demuestra si todo funciona bajo presión.
El error: pensar que seguridad termina en prevención#
Una organización puede invertir mucho en controles preventivos y aun así no estar preparada para responder bien.
Puede tener políticas, firewalls, controles de acceso, cifrado, herramientas de monitoreo, pruebas de seguridad y procesos de cumplimiento. Pero si no puede detectar rápido un evento crítico, entender su impacto, coordinar equipos, contener el incidente, recuperar operación y explicar qué ocurrió, su confianza operativa sigue siendo débil.
En banca digital, algunos incidentes no se presentan como una caída total. A veces son degradaciones parciales, errores intermitentes, intentos de abuso automatizado, anomalías en APIs, fallas de terceros, problemas de identidad o eventos de fraude que parecen incidentes técnicos.
Por eso, la pregunta no debe ser solo:
¿Estamos protegidos?
También debe ser:
¿Podemos detectar, responder, recuperar y aprender cuando algo ocurra?
El National Institute of Standards and Technology (NIST), en The NIST Cybersecurity Framework (CSF) 2.0, plantea funciones como gobernar, identificar, proteger, detectar, responder y recuperar. Esa estructura evita reducir la ciberseguridad a controles preventivos: la seguridad madura también incluye gobierno, detección, respuesta, recuperación y mejora continua.
Resiliencia operativa: más allá de continuidad de negocio#
La resiliencia operativa suele asociarse con continuidad de negocio, recuperación ante desastres o planes de contingencia. Eso es parte de la conversación, pero no la agota.
El Basel Committee on Banking Supervision (BCBS), en Principles for operational resilience, plantea la resiliencia operativa como la capacidad de una entidad para entregar operaciones críticas durante una disrupción. Esta idea desplaza el foco desde “recuperar sistemas” hacia sostener servicios críticos.
En banca digital, esto cambia la forma de diseñar seguridad. No basta con proteger componentes aislados. Hay que entender qué servicios son críticos, qué procesos los sostienen, qué datos participan, qué APIs conectan capacidades, qué terceros son relevantes, qué eventos indican degradación, qué evidencia se necesita y qué capacidad real existe para responder.
La resiliencia operativa no es una carpeta de continuidad. Es una propiedad de diseño, gobierno y operación.
El CISO como habilitador de resiliencia#
El CISO aporta valor porque entiende amenazas, exposición, controles, monitoreo, respuesta, vulnerabilidades, identidades, datos sensibles, terceros y riesgo tecnológico.
Pero no puede construir resiliencia solo.
Necesita trabajar con arquitectura, infraestructura, aplicaciones, datos, operaciones, continuidad, fraude, atención a clientes, riesgo, compliance, proveedores y negocio. Su responsabilidad no debería limitarse a “evitar incidentes”. También debe ayudar a que la organización responda mejor cuando los incidentes ocurran.
Eso implica participar en decisiones como qué operaciones digitales son críticas, qué señales deben monitorearse, qué eventos deben llegar al Security Information and Event Management (SIEM), qué incidentes deben correlacionarse con fraude, qué datos permiten reconstruir un evento, qué dependencias de terceros requieren monitoreo y qué aprendizajes deben cambiar arquitectura y controles.
Un CISO estratégico no solo pregunta si existe un control. Pregunta si la organización podría operar bajo presión.
Arquitectura: donde la resiliencia se vuelve diseño#
La resiliencia no aparece espontáneamente en producción. Se diseña.
Arquitectura tiene un rol central porque permite entender dependencias, flujos, dominios, datos, integraciones, componentes, proveedores, procesos, canales, controles y escenarios de falla.
Cuando arquitectura y CISO trabajan juntos, pueden responder preguntas fundamentales: qué capacidades críticas dependen de una solución, qué datos deben protegerse, qué integración podría fallar, qué API puede ser abusada, qué evento indicaría comportamiento anómalo, qué pasa si un proveedor queda indisponible, qué logs serían necesarios para investigar y qué evidencia queda después del evento.
The Open Group, mediante TOGAF Standard, ayuda a entender la arquitectura empresarial como una disciplina que conecta estrategia, capacidades, procesos, información, aplicaciones y tecnología. Esa visión es útil para resiliencia porque obliga a dejar de mirar solo componentes técnicos y empezar a mirar capacidades completas.
Una institución financiera no necesita únicamente aplicaciones disponibles. Necesita capacidades digitales resilientes.
Caso aplicado: un incidente que no parece incidente#
Imaginemos una institución financiera digital que empieza a recibir quejas de clientes porque algunas solicitudes de crédito no avanzan correctamente.
El canal digital responde. La aplicación no está caída. La infraestructura está dentro de umbrales. El core opera normalmente. Los tableros técnicos no muestran una indisponibilidad mayor.
Sin embargo, los clientes enfrentan fricción. Algunos expedientes quedan incompletos. Algunas validaciones no regresan a tiempo. Algunos usuarios reintentan varias veces. El equipo de atención empieza a recibir casos, pero no tiene una explicación clara.
Una mirada limitada diría:
“No hay incidente. El sistema está arriba.”
Una mirada de resiliencia preguntaría: qué paso del flujo está fallando, qué clientes fueron afectados, qué API externa tuvo latencia, qué validación no regresó a tiempo, si hay patrón por canal o segmento, si existe intento de abuso automatizado, qué eventos llegaron al SIEM, qué logs permiten reconstruir el caso y qué cambio reciente pudo introducir la degradación.
Aquí aparece una diferencia importante.
La disponibilidad técnica puede decir que todo está bien. La resiliencia operativa pregunta si la capacidad crítica funciona para el cliente.
Y para responder eso se necesitan datos, observabilidad, arquitectura y seguridad trabajando juntas.
Observabilidad: ver más allá de la infraestructura#
La observabilidad no puede limitarse a métricas técnicas.
En banca digital, una operación crítica puede cruzar canal móvil, API management, servicios de negocio, motor antifraude, motor de decisiones, core bancario, proveedores externos, mensajería, bases de datos, sistemas de atención y repositorios de evidencia.
Si cada componente observa solo su propia parte, la organización ve fragmentos.
La resiliencia exige correlación entre métricas de infraestructura, logs de aplicación, trazas distribuidas, eventos de negocio, errores visibles al cliente, eventos de seguridad, eventos de fraude, estado de integraciones, incidentes, tickets, cambios recientes, datos de terceros e indicadores de experiencia.
El CISO necesita esta visibilidad para detectar anomalías. Arquitectura la necesita para entender dependencias. Operación la necesita para responder. Riesgo la necesita para evaluar impacto. Compliance la necesita para demostrar evidencia. Negocio la necesita para proteger experiencia y confianza.
Sin observabilidad, la organización responde tarde y aprende poco.
Seguridad, fraude y operación no deberían vivir separados#
En banca digital, algunos eventos no respetan los organigramas.
Un patrón de abuso puede parecer error técnico. Una degradación de canal puede parecer incidente operativo. Una campaña de bots puede parecer tráfico legítimo. Un ataque a APIs puede manifestarse como aumento de errores. Una vulnerabilidad puede facilitar fraude. Un incidente de proveedor puede afectar experiencia de cliente y cumplimiento.
Por eso, separar demasiado seguridad, fraude y operación puede retrasar la respuesta.
El CISO debe colaborar con fraude, riesgo operacional, operaciones digitales, arquitectura y atención al cliente para diseñar una visión común de eventos críticos.
La pregunta no es solo si hubo un ataque. La pregunta es qué impacto tuvo en clientes, operaciones, datos, transacciones, reputación y cumplimiento.
Terceros: una parte crítica de la resiliencia#
La banca digital depende cada vez más de terceros: nube, software como servicio, burós, proveedores de identidad, procesadores, redes de pago, antifraude, mensajería, analítica, monitoreo, seguridad y servicios especializados.
La resiliencia no puede diseñarse como si todo estuviera bajo control interno.
Por eso, el CISO y arquitectura deben participar en la evaluación de terceros desde una perspectiva de criticidad, datos compartidos, controles de seguridad, integración técnica, monitoreo, continuidad, notificación de incidentes, evidencias, pruebas, dependencia operativa, planes de salida y concentración de proveedor.
El Digital Operational Resilience Act (DORA) de la Unión Europea, publicado como Regulation (EU) 2022/2554, es una referencia internacional relevante porque fortalece la conversación sobre riesgo tecnológico, incidentes, pruebas de resiliencia y terceros TIC en el sector financiero.
Aunque DORA pertenece al contexto europeo, su mensaje estratégico es útil para México y Latinoamérica: la resiliencia digital ya no es solo un asunto interno de infraestructura. También incluye proveedores, contratos, supervisión, incidentes, continuidad y capacidad de demostrar control.
Respuesta a incidentes: no improvisar bajo presión#
Una organización no debería diseñar su respuesta a incidentes durante el incidente.
La respuesta debe estar preparada.
Eso implica definir tipos de incidentes, criterios de severidad, responsables, escalamiento, canales de comunicación, runbooks, tiempos objetivo, evidencias, relación con fraude, relación con continuidad, relación con jurídico y compliance, comunicación a clientes cuando aplique, criterios de cierre, postmortem y acciones correctivas.
El CISO puede liderar o coordinar varios elementos, pero la respuesta real requiere tecnología, seguridad, riesgo, negocio, atención, legal, compliance, comunicación, proveedores y dirección.
Por eso, la resiliencia debe ensayarse. No solo documentarse.
Una organización que nunca prueba su respuesta probablemente sobreestima su capacidad real.
Evidencia: explicar qué ocurrió y qué se hizo#
En seguridad y resiliencia, la evidencia no es un detalle administrativo. Es la capacidad de explicar.
Explicar qué ocurrió, cuándo empezó, cómo se detectó, qué clientes fueron afectados, qué controles operaron, qué decisiones se tomaron, qué acciones se ejecutaron, qué riesgo quedó abierto, qué se comunicó, qué se recuperó y qué se aprendió.
Sin evidencia, la organización depende de memoria, correos, capturas y reconstrucciones incompletas.
La arquitectura debe diseñar cómo se genera evidencia: logs estructurados, trazabilidad de eventos, cambios registrados, correlación de incidentes, bitácoras de decisión, evidencias de acceso, pruebas ejecutadas, resultados de monitoreo, seguimiento de acciones correctivas y cierre formal de incidentes.
La evidencia más fuerte nace de una operación bien diseñada.
Automatización: responder más rápido sin perder control#
La automatización puede fortalecer la resiliencia si se diseña con criterio. Puede ayudar a detectar patrones anómalos, abrir tickets, enrutar alertas, activar runbooks, aislar componentes, bloquear patrones maliciosos, revocar accesos, escalar incidentes, cambiar tráfico, generar evidencia y ejecutar validaciones.
Pero automatizar sin gobierno puede ser riesgoso.
Una respuesta automática mal calibrada puede afectar clientes. Una regla demasiado agresiva puede bloquear operaciones legítimas. Una alerta mal diseñada puede generar fatiga. Un runbook sin contexto puede ocultar la causa raíz. Una automatización sin evidencia puede dificultar auditoría.
Por eso, automatizar respuesta exige datos confiables, límites claros, revisión humana cuando aplique, trazabilidad y criterios de reversibilidad.
La meta no es automatizar todo. Es automatizar lo que mejora velocidad, consistencia y control.
Qué debe diseñarse para construir confianza operativa#
Una arquitectura de seguridad orientada a resiliencia debe incluir capacidades mínimas.
Primero, identificación de operaciones críticas: servicios, procesos, canales y capacidades críticos para clientes, operación, riesgo, cumplimiento y negocio.
Segundo, mapa de dependencias: aplicaciones, datos, infraestructura, APIs, proveedores, identidades, procesos y responsables.
Tercero, observabilidad integrada: correlación de señales técnicas, negocio, seguridad, fraude, experiencia de cliente e incidentes.
Cuarto, runbooks y escalamiento. La respuesta debe estar diseñada antes del incidente, con pasos, responsables, criterios y evidencias.
Quinto, gestión de terceros críticos. Los proveedores relevantes deben evaluarse no solo por funcionalidad y costo, sino por seguridad, continuidad, monitoreo, incidentes y salida.
Sexto, evidencia operativa. Los controles y eventos deben generar trazabilidad suficiente para explicar decisiones, acciones y recuperación.
Séptimo, aprendizaje posterior. Cada incidente debe alimentar mejoras en arquitectura, controles, monitoreo, capacitación, proveedores, procesos y gobierno.
Una organización que no aprende de sus incidentes repite sus fragilidades.
Antipatrones de seguridad y resiliencia#
Algunos antipatrones aparecen con frecuencia: seguridad solo preventiva, resiliencia delegada a infraestructura, observabilidad fragmentada, incidentes sin impacto de negocio, terceros fuera del diseño, evidencia reconstruida después, runbooks no probados y lecciones aprendidas que no cambian arquitectura.
Estos antipatrones muestran que la resiliencia no es un documento. Es una capacidad viva.
Mi postura: el CISO no solo protege; ayuda a sostener operación#
Una visión limitada del CISO lo reduce a controles, vulnerabilidades, auditorías o incidentes.
Una visión más madura lo entiende como una función que ayuda a sostener confianza operativa.
En banca digital, proteger no es suficiente si la organización no puede responder. Responder no es suficiente si no puede recuperar. Recuperar no es suficiente si no puede explicar. Explicar no es suficiente si no puede aprender.
El CISO estratégico debe ayudar a que seguridad se conecte con resiliencia, arquitectura, datos, observabilidad, continuidad, fraude, operación y gobierno.
Porque la confianza del cliente no depende de organigramas.
Depende de que el servicio funcione, proteja, responda y se recupere cuando más importa.
Reflexión de arquitectura: resiliencia es visibilidad diseñada#
Como arquitecto, considero que uno de los errores más frecuentes es diseñar soluciones que funcionan bien en condiciones normales, pero son difíciles de entender cuando fallan.
Eso no es suficiente.
Una arquitectura profesional debe explicar cómo funciona una solución, pero también cómo se observa, cómo se protege, cómo se degrada, cómo se recupera y cómo se aprende.
La resiliencia exige visibilidad diseñada: visibilidad de dependencias, datos, integraciones, eventos, decisiones, impacto y controles.
Cuando esa visibilidad no existe, la organización responde con suposiciones. Y en un incidente, las suposiciones cuestan tiempo.
Reflexión CTO: la confianza operativa es parte de la estrategia#
Desde una mirada CTO, la resiliencia no debe tratarse como un tema técnico de segundo nivel.
Es parte de la estrategia.
Una institución financiera digital compite por experiencia, disponibilidad, seguridad, rapidez, confianza y capacidad de respuesta. Si no puede sostener operaciones críticas durante eventos adversos, su propuesta digital pierde credibilidad.
Por eso, la conversación ejecutiva no debería limitarse a preguntar:
¿Estamos seguros?
También debería preguntar:
¿Podemos demostrar que entendemos nuestras operaciones críticas, sus dependencias, sus riesgos, sus puntos de falla y nuestra capacidad de respuesta?
Esa demostración exige arquitectura, datos, evidencia y gobierno.
La resiliencia no se improvisa en crisis. Se construye antes.
Conclusión: confianza operativa por diseño#
La ciberseguridad moderna no termina en prevenir ataques.
En banca digital, seguridad también significa detectar, responder, recuperar, explicar y aprender. Significa proteger datos, pero también sostener operaciones críticas. Significa reducir exposición, pero también construir capacidad de respuesta. Significa cumplir, pero también demostrar que la organización puede operar bajo presión.
El CISO, arquitectura, riesgo, compliance y operación deben trabajar juntos para que la resiliencia no sea un documento, sino una capacidad real.
Porque una organización financiera no será juzgada solo por si tuvo o no incidentes. Será juzgada por cómo los anticipó, cómo los gestionó, cómo protegió a sus clientes, cómo explicó lo ocurrido y cómo mejoró después.
La confianza operativa no se declara. Se diseña, se opera, se evidencia y se aprende.
Glosario breve#
CISO — Chief Information Security Officer
Ejecutivo responsable de liderar la estrategia de seguridad de la información y ciberseguridad. En banca digital, su rol debe conectarse con resiliencia, arquitectura, riesgo, operación y confianza.
Resiliencia operativa
Capacidad de una organización para mantener operaciones críticas durante una disrupción, responder, recuperarse, adaptarse y aprender.
Arquitectura de seguridad
Disciplina que diseña principios, patrones, controles y estructuras para proteger sistemas, datos, identidades, integraciones, operaciones y capacidades digitales.
Observabilidad
Capacidad de entender el estado y comportamiento de un sistema mediante señales como métricas, logs, trazas, eventos y datos operativos.
SIEM — Security Information and Event Management
Capacidad o plataforma para recolectar, correlacionar y analizar eventos de seguridad con fines de detección, investigación y respuesta.
SOC — Security Operations Center
Función o equipo encargado de monitorear, detectar, analizar y responder a eventos e incidentes de seguridad.
Runbook
Conjunto de pasos definidos para ejecutar una respuesta operativa ante incidentes, alertas, fallas o escenarios recurrentes.
DORA — Digital Operational Resilience Act
Regulación de la Unión Europea orientada a fortalecer la resiliencia operativa digital del sector financiero, incluyendo riesgo tecnológico, incidentes, pruebas y terceros TIC.
NIST CSF — NIST Cybersecurity Framework
Marco del National Institute of Standards and Technology para gestionar riesgos de ciberseguridad mediante funciones como gobernar, identificar, proteger, detectar, responder y recuperar.
BCBS — Basel Committee on Banking Supervision
Comité internacional de supervisión bancaria que emite principios y recomendaciones para fortalecer la gestión de riesgos, supervisión y estabilidad del sistema financiero.
TOGAF — The Open Group Architecture Framework
Estándar de arquitectura empresarial desarrollado por The Open Group. Ayuda a conectar estrategia, capacidades, procesos, información, aplicaciones y tecnología.
Referencias#
National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 — Estados Unidos, referencia de adopción internacional para gestión de riesgos de ciberseguridad
https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 PDF
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdfBasel Committee on Banking Supervision (BCBS), Principles for operational resilience — alcance global para banca, con adopción proporcional según contexto regulatorio
https://www.bis.org/bcbs/publ/d516.pdfEuropean Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA) — Unión Europea; referencia útil para resiliencia operativa digital, riesgo TIC, incidentes, pruebas y terceros críticos
https://eur-lex.europa.eu/eli/reg/2022/2554/oj/engEuropean Insurance and Occupational Pensions Authority (EIOPA), Digital Operational Resilience Act (DORA) — Unión Europea
https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_enThe Open Group, The TOGAF Standard — alcance global para arquitectura empresarial
https://www.opengroup.org/togafComisión Nacional Bancaria y de Valores (CNBV), Sitio institucional — México
https://www.gob.mx/cnbvBanco de México, Seguridad de la información — México
https://www.banxico.org.mx/sistema-financiero/seguridad-informacion-banco.html