Biblioteca / Gobernanza TI
Guia de Gobernanza TI Enterprise COBIT + ITIL 4
Marco completo de gobernanza tecnologica con RACI KPIs politicas operativas y gestion de riesgos.
Tabla de contenido
Capitulo 1
Fundamentos de gobernanza de TI
La gobernanza de TI no es burocracia; es el sistema que permite que la tecnologia sirva al negocio de forma predecible controlada y medible.
Diferencia entre gobernanza gestion y operaciones
| Nivel | Pregunta que responde | Responsable | Horizonte |
|---|---|---|---|
| Gobernanza | Estamos haciendo lo correcto? | Consejo directivo CTO | Estrategico 1-5 anos |
| Gestion | Lo estamos haciendo correctamente? | CTO IT Manager | Tactico trimestre-ano |
| Operaciones | Lo estamos haciendo? | Tech Lead Ops Engineers | Operativo diario-semanal |
Niveles de madurez
| Nivel | Nombre | Caracteristicas |
|---|---|---|
| 1 | Inicial | Sin procesos formales; todo depende de personas clave |
| 2 | Reactivo | Procesos existen pero no documentados; se responde a problemas |
| 3 | Definido | Procesos documentados y seguidos; metricas basicas activas |
| 4 | Gestionado | Metricas completas; mejora continua; riesgos monitoreados |
| 5 | Optimizado | Mejora continua automatizada; benchmarking externo |
La mayoria de PYMEs tecnologicas estan en nivel 2. Este documento te lleva del nivel 2 al nivel 3 en 6 meses con implementacion consistente.
Capitulo 2
Estructura organizacional y modelo RACI
Claridad de roles es la base de cualquier organizacion que funcione. Sin saber quien decide que todo se convierte en reuniones sin conclusiones.
El modelo RACI
R Responsible ejecuta la tarea. A Accountable rinde cuentas. C Consulted da input antes. I Informed es notificado despues.
| Proceso | CTO | IT Manager | Architect | DevOps Lead | Seguridad |
|---|---|---|---|---|---|
| Estrategia tecnologica | A | C | C | I | C |
| Aprobacion cambios produccion | A | R | C | R | C |
| Contratacion proveedores cloud | A | R | C | I | I |
| Respuesta a incidente P1 | C | A | C | R | R |
| Definicion de arquitectura | C | C | A | C | C |
| Revision de accesos IAM | I | A | I | R | R |
El comite de arquitectura tecnica
- Frecuencia: quincenal 2h maximo
- Composicion: CTO + Architect + representante DevOps + representante Desarrollo
- Decisiones del comite: nuevos servicios cloud cambios de stack migraciones
- Proceso: RFC enviado 48h antes discusion en reunion decision documentada en ADR
Capitulo 3
Politicas operativas de TI
Las politicas son el contrato entre TI y la organizacion sobre como se trabaja.
Las 12 politicas esenciales
| Num | Politica | Revision | Prioridad |
|---|---|---|---|
| 1 | Uso aceptable de tecnologia | Anual | Alta |
| 2 | Gestion de contrasenas y credenciales | Anual | Critica |
| 3 | Control de cambios en produccion | Semestral | Critica |
| 4 | Backup y recuperacion de desastres | Semestral | Critica |
| 5 | Gestion de accesos e identidades | Semestral | Critica |
| 6 | Clasificacion y manejo de datos | Anual | Alta |
| 7 | BYOD dispositivos personales | Anual | Media |
| 8 | Acceso remoto y VPN | Anual | Alta |
| 9 | Gestion de vulnerabilidades | Semestral | Alta |
| 10 | Respuesta a incidentes | Semestral | Critica |
| 11 | Continuidad de negocio | Anual | Alta |
| 12 | Uso de servicios cloud y SaaS externos | Anual | Media |
Toda politica debe ser redactada por el responsable aprobada por el CTO comunicada con confirmacion de lectura y revisada en la fecha establecida.
Capitulo 4
Gestion del cambio y control de configuracion
El control de cambios no obstaculiza al equipo lo protege. La mayoria de incidentes graves ocurren durante cambios en produccion.
Tipos de cambio y proceso
| Tipo | Definicion | Aprobacion | Ventana |
|---|---|---|---|
| Estandar | Bajo riesgo procedimiento conocido | Ninguna pre-aprobado | Cualquier momento |
| Normal | Planificado con analisis de impacto | CAB semanal | Ventana programada |
| Emergencia | Urgente para resolver P1 o P2 | CTO post-hoc si necesario | Inmediata con doc |
Flujo de aprobacion de cambio normal
- Ingeniero crea RFC con descripcion impacto plan de rollback y ventana propuesta
- RFC distribuido al equipo con 48h de antelacion minima
- CAB revisa en reunion semanal de 30 minutos
- Cambio aprobado se ejecuta en la ventana acordada
- Post-cambio confirmar funcionamiento en max 1h
- Documentar resultado en el registro de cambios
Si usas Terraform y GitHub Actions el pull request es tu RFC. La revision del PR es tu CAB. El merge es tu aprobacion. El historial de commits es tu auditoria.
Capitulo 5
KPIs e indicadores de rendimiento de TI
Los KPIs de TI deben responder preguntas que el negocio se hace no solo metricas que interesan al equipo tecnico.
Marco de KPIs por dimension
| Dimension | KPI | Formula | Objetivo |
|---|---|---|---|
| Disponibilidad | Uptime de servicios criticos | Tiempo activo / total x100 | >=99.5% |
| Velocidad | Frecuencia de deploy | Deploys a produccion por semana | >=2 por semana |
| Calidad | Tasa de fallos en deploy | Deploys fallidos / total x100 | <=5% |
| Seguridad | MTTD tiempo medio de deteccion | Promedio horas hasta detectar incidente | <=2 horas |
| Seguridad | MTTR tiempo medio de recuperacion | Promedio horas hasta resolver | <=4 horas |
| Costo | Costo cloud por usuario activo | Gasto cloud / usuarios activos | Tendencia decreciente |
Estructura del informe mensual para direccion
- Semaforo general verde amarillo rojo con una frase de contexto
- Tabla de KPIs: valor actual vs objetivo vs mes anterior
- Top 3 logros del mes en terminos de impacto de negocio
- Top 3 riesgos activos y su estado
- Inversion del mes: que se gasto y en que
- Proximo mes: 3 prioridades con responsable y fecha
Capitulo 6
Gestion de riesgos tecnologicos
La gestion de riesgos no es eliminar todos los riesgos; es tomar decisiones informadas sobre cuales aceptar y cuales mitigar.
Registro de riesgos TI
| ID | Riesgo | Probabilidad | Impacto | Estrategia | Responsable |
|---|---|---|---|---|---|
| R01 | Dependencia de un unico proveedor cloud | Media | Alto | Mitigar: plan DR en GCP | CTO |
| R02 | Clave IAM expuesta en repositorio | Baja | Critico | Mitigar: escaneo automatizado de secretos | Seguridad |
| R03 | Sin documentacion de arquitectura actualizada | Alta | Medio | Mitigar: ADR obligatorio en PRs | Architect |
| R04 | Unico punto de conocimiento en sistemas legacy | Alta | Alto | Mitigar: knowledge transfer sessions | IT Manager |
| R05 | Proveedor SaaS critico sin SLA documentado | Media | Medio | Transferir: revisar contrato | IT Manager |
Define con direccion cual es el apetito de riesgo antes de evaluar riesgos individuales. Sin esta conversacion las evaluaciones son subjetivas y no comparables.
Capitulo 7
Gestion de proveedores y terceros
Los proveedores externos son una extension del riesgo operativo de la organizacion.
Evaluacion inicial de proveedores
| Criterio | Peso | Fuente de verificacion |
|---|---|---|
| Certificaciones de seguridad ISO 27001 SOC 2 | 25% | Solicitar certificado vigente |
| Historial de disponibilidad uptime | 20% | Status page publica + referencias |
| Politica de privacidad y manejo de datos | 20% | Documentacion legal del proveedor |
| Notificacion de brechas de seguridad | 15% | DPA Data Processing Agreement |
| Condiciones de portabilidad y salida | 10% | Contrato de servicio |
| Soporte tiempos de respuesta documentados | 10% | SLA del contrato |
Clausulas contractuales minimas
- Niveles de servicio con penalizaciones economicas por incumplimiento
- Notificacion de brechas de seguridad en maximo 72 horas
- Derecho de auditoria o certificacion equivalente por tercero independiente
- Portabilidad: exportacion de datos en formato estandar sin costo
- Offboarding: revocacion de accesos y eliminacion de datos en 30 dias
Capitulo 8
Comunicacion ejecutiva y reporte a direccion
La comunicacion con la direccion es una habilidad tecnica como programar. Se aprende se practica y se mejora.
Traducir metricas tecnicas a impacto de negocio
| Metrica tecnica | Traduccion para direccion |
|---|---|
| Uptime 99.5% | El servicio estuvo caido 44 horas al ano con impacto directo en ingresos |
| MTTR de 4 horas | Cada fallo mayor cuesta en promedio 4 horas de operacion paralizada |
| 40 vulnerabilidades criticas | 40 puertas abiertas por las que un atacante podria entrar ahora |
| Deuda tecnica 35% | 1 de cada 3 horas de desarrollo se gasta en codigo heredado |
| Cobertura backup 85% | El 15% de datos podrian perderse permanentemente ante un desastre |
Presentacion al consejo 5 slides
- Slide 1: Semaforo de estado con contexto en 2 lineas
- Slide 2: Logros del trimestre en terminos de impacto de negocio
- Slide 3: Riesgos top 3 activos y estado de mitigacion
- Slide 4: Inversion del trimestre y ROI estimado
- Slide 5: Plan del proximo trimestre con 3 prioridades y fechas
Capitulo 9
Hoja de ruta y apendices
La implementacion de gobernanza TI es un proyecto. Necesita un plan recursos y un responsable.
Plan de 12 meses hacia nivel 3
| Trimestre | Foco | Entregables clave |
|---|---|---|
| Q1 Fundamentos | Documentar lo que existe | RACI inicial inventario 5 politicas criticas |
| Q2 Control | Implementar controles basicos | Proceso de cambios activo KPIs definidos |
| Q3 Metricas | Medir y visibilizar | Dashboard ejecutivo mensual revision de proveedores |
| Q4 Mejora | Optimizar con datos | Revision de todas las politicas segunda evaluacion de madurez |
Implementar gobernanza completa toma tiempo. Prioriza lo que mas duele hoy. El orden importa menos que empezar.