Ir al contenido principal

Cuando una decisión técnica no es bien vista (hasta que se vuelve inevitable)

 En una organización pública donde trabajé, la infraestructura tecnológica tenía más de diez años de antigüedad.

El enfoque de la gerencia general, con formación legal y no tecnológica, era claro: no invertir en tecnología y solicitar a la casa matriz la donación de equipos antiguos, con siete o incluso diez años de uso.

Yo no estaba de acuerdo.

No porque despreciara una donación, sino porque eso no resolvía el problema principal. Era poner pañitos húmedos sobre una herida estructural que seguía abierta.

Desde mi rol insistí en que la plataforma ya estaba agotada y que seguir incorporando equipamiento viejo solo prolongaba el riesgo. Ese desacuerdo me convirtió rápidamente en “el conflictivo”.

La situación escaló al punto de que la propia gerencia decidió llevar el caso a la casa matriz, con la expectativa de que el área de TI validara su posición y dejara en evidencia que yo estaba equivocado.

Ocurrió lo contrario.

Presenté información, informes técnicos y argumentos claros sobre riesgo, continuidad y sostenibilidad operativa. No fue una discusión ideológica ni personal, fue una discusión basada en hechos. El resultado fue una decisión intermedia: se recibieron algunos equipos en donación, pero también se aprobó la adquisición de infraestructura nueva.

Esa decisión marcó el inicio de una nueva etapa para la organización.

Desde entonces entendí algo que he vuelto a ver muchas veces: las decisiones técnicas correctas no siempre son bien vistas al comienzo, especialmente cuando implican inversión o incomodidad. Pero cuando están bien fundamentadas, terminan imponiéndose porque la operación real no perdona atajos.

Trabajo exactamente ahí: donde la tecnología deja de ser solo técnica y se convierte en decisiones (a veces incómodas) que el negocio tiene que poder sostener.

Comentarios

Entradas más populares de este blog

¿Por qué CIS Controls antes que cualquier otra cosa? Serie: CIS Controls — Post 1 de 5

SERIE CIS CONTROLS · POST 1 DE 5 Estrategia · Liderazgo en TI ¿Por qué CIS Controls antes que cualquier otra cosa? El argumento estratégico para empezar por donde el riesgo es mayor, no por donde el proceso es más visible. Priorización por riesgo No todos los controles valen lo mismo Lenguaje de negocio Traduce técnica en riesgo medible Complementa ISO 27001 Donde la norma dice qué, CIS dice cómo LB Luis Bolívar IT Manager · Cybersecurity Insights #CISControls #Ciberseguridad Serie CIS Controls — Post 1 de 5: el argumento estratégico para empezar por donde el riesgo es mayor. Cuando TechCorp Latam implementó CIS Controls por primera vez, lo hizo después de un ransomware que comprometió el 65% de sus servidores. No fue una decisión estratégica planificada; fue un...

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos Serie · Post 2 de 6 🔍 Función ID — IDENTIFY NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos No puedes proteger lo que no sabes que tienes. IDENTIFY es el mapa que toda organización necesita antes de implementar cualquier control de seguridad. Analizamos sus 3 categorías y construimos el inventario de TechCorp Latam. 📅 Publicación 2 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Inventario desde cero El error más costoso en ciberseguridad: proteger sin saber qué tienes Imagina contratar una empresa de seguridad para custodiar tu edificio, pero nadie te da el plano del edificio. ¿Cuántas entradas hay? ¿Dónde están los archivos más valiosos? ¿Qué puertas dan al exterior? Sin ese plano, la seguridad es aleatoria. Exactamente eso ocurre cuando una organización invierte en firewalls, antivirus y monitoreo sin haber hecho antes un trabajo sistemático de identif...

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Serie · Post 5 de 6 🚨 Función RS — RESPOND NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Todo lo que TechCorp Latam construyó en GOVERN, IDENTIFY, PROTECT y DETECT llegó a su momento de verdad: un ataque de ransomware real. Esta es la historia de cómo respondieron, qué salió bien y qué lección pagaron caro. 📅 Publicación 5 de 6 ⏱ Lectura: ~12 min 🏢 TechCorp Latam · El momento de la verdad El momento para el que todo lo anterior te prepara Llevan cuatro funciones construyendo su programa. Tienen gobernanza, inventario de activos, controles activos y visibilidad de red. Y aun así, el incidente ocurre. Porque esa es la realidad del riesgo cibernético: los controles reducen la probabilidad, no la eliminan . El objetivo de un programa maduro de ciberseguridad no es hacer que los incidentes sean imposibles — es hacer que sean contenibles, detectables y recuper...