Biblioteca / Gobernanza Enterprise

Administracion y Gobernanza de Operaciones Tecnologicas Enterprise

Modelo operativo completo: politicas control de cambios auditoria cloud marcos de cumplimiento y gestion del conocimiento.

ISO 20000COBITITIL 4ADRCABAuditoria cloudOKRs TIPost-mortem
PDF · 40 paginasNivel: AvanzadoActualizado mayo 2026Descargar PDF

Capitulo 1

El modelo operativo tecnologico enterprise

Un modelo operativo tecnologico define como una organizacion gestiona entrega y evoluciona sus capacidades tecnologicas. Sin un modelo explicito las organizaciones operan por inercia.

Las cuatro dimensiones

DimensionQue defineSintomas de falloSolucion
PersonasRoles responsabilidades y culturaTodo depende de una persona claveRACI claro documentacion cross-training
ProcesosComo se toman decisiones y ejecutan cambiosReuniones sin conclusiones; incidentes sin procesoRunbooks politicas documentadas y seguidas
TecnologiaQue herramientas se usan y como se integranHerramientas duplicadas datos en silosStack tecnologico definido y estandar
DatosQue metricas se miden y como se usan para decidirDecisiones por intuicion sin visibilidad de costosKPIs dashboards cultura data-driven

Herramienta de diagnostico de madurez

Evalua cada area de 1 (caotico) a 5 (optimizado) y promedia el resultado:

Area a evaluarPuntuacion 1-5
Tienes documentado quien decide que en TI?
Existe proceso formal de control de cambios en produccion?
Hay runbooks para los 5 incidentes mas frecuentes?
Se miden y reportan KPIs de TI mensualmente a direccion?
Existe politica de backup verificada con pruebas regulares?
Los nuevos ingresos pueden ser productivos en 48h?
Existe un registro de riesgos tecnologicos actualizado?
Hay proceso documentado de gestion de proveedores?
Resultado

1-2: prioridad urgente. 2-3: en proceso continua. 3-4: buen nivel refina. 4-5: excelente comparte tu modelo.

Capitulo 2

Diseno y ciclo de vida de politicas operativas

Las politicas operativas son el contrato interno de la organizacion sobre como se trabaja. Sin ellas cada situacion nueva requiere una decision desde cero.

Anatomia de una politica efectiva

ComponenteDescripcionEjemplo
IdentificadorCodigo unico de la politicaPOL-OPS-003
TituloNombre descriptivo y claroControl de Cambios en Produccion
PropositoPor que existe en 2-3 frasesPrevenir interrupciones por cambios no controlados
AlcanceA quien y que aplicaTodo el equipo TI sistemas de produccion y staging
DeclaracionLas reglas concretasTodo cambio requiere aprobacion previa del CAB
ExcepcionesCasos fuera de la normaP1 puede ejecutar con aprobacion post-hoc del CTO
ResponsabilidadesQuien hace queIT Manager aprueba DevOps ejecuta Seguridad revisa
RevisionCuando se revisa y expiraSemestral proxima noviembre 2026

Plantilla de politica en Markdown

markdown - estructura de politica operativa
# POL-OPS-003: Control de Cambios en Produccion
Version: 2.1 | Fecha: Mayo 2026 | Estado: Vigente
Propietario: IT Manager | Aprobador: CTO

## Proposito
Garantizar que todos los cambios en produccion sean planificados,
revisados, aprobados y documentados para minimizar interrupciones.

## Alcance
Todos los cambios en sistemas de produccion y staging: codigo,
infraestructura, configuraciones y bases de datos.

## Tipos de cambio
| Tipo       | Definicion                   | Aprobacion      |
|------------|------------------------------|-----------------|
| Estandar   | Bajo riesgo conocido         | Pre-aprobada    |
| Normal     | Requiere analisis de impacto | CAB semanal     |
| Emergencia | Respuesta a P1 o P2 activo  | CTO post-hoc    |

## Proceso normal
1. RFC con 48h de antelacion minima
2. Revision del equipo
3. Aprobacion en CAB semanal
4. Ejecucion en ventana acordada
5. Confirmacion y documentacion del resultado

## Revision
Semestral. Proxima: noviembre 2026.

Capitulo 3

Gestion de incidentes y continuidad operativa

La calidad de la respuesta a un incidente determina el impacto final en clientes reputacion y operacion. La preparacion es la unica variable que puedes controlar.

Proceso de gestion de incidentes

FaseActividadesResponsableTiempo objetivo
DeteccionAlerta de monitoreo o reporte de usuarioSistema automatizadomenor 2 min
RegistroCrear ticket con timestamp y sintomasOn-call engineermenor 5 min
ClasificacionDeterminar P1-P4 con arbol de decisionOn-call engineermenor 10 min
EscalamientoNotificar segun clasificacionOn-call engineermenor 15 min P1 P2
DiagnosticoIdentificar causa raizEquipo tecnicoSegun complejidad
ResolucionImplementar la correccionEquipo tecnicoSegun RTO del servicio
ComunicacionActualizar stakeholders cada 30 min en P1 P2IT ManagerDurante el incidente
Post-mortemAnalisis de causa raiz y plan de mejoraTodo el equipoDentro de 48h

Plantilla de post-mortem sin culpas

markdown - post-mortem template
# Post-Mortem: [Titulo del incidente]
Fecha: | Duracion: | Severidad: | Autor:

## Resumen ejecutivo (2 parrafos)
Que ocurrio, cuando, impacto en usuarios y negocio.

## Cronologia
| Timestamp UTC | Evento |
|---------------|--------|
| 14:03 | Primera alerta de CloudWatch |
| 14:07 | On-call confirmo degradacion |
| 14:52 | Causa raiz identificada |
| 15:31 | Servicio restaurado al 100% |

## Causa raiz
Descripcion tecnica precisa de que fallo y por que.

## Impacto
Usuarios afectados: X | Duracion: Y min | Costo: $Z

## Plan de accion
| Accion | Responsable | Fecha limite | Estado |
|--------|-------------|--------------|--------|
| Agregar alerta X | DevOps | 2026-06-01 | Pendiente |
Cultura blameless

Los post-mortems sin culpas son mas efectivos. Un equipo que teme el post-mortem oculta informacion. Un equipo que aprende de el se vuelve mas resiliente con cada incidente.

Capitulo 4

Control de cambios en entornos productivos

El control de cambios protege la estabilidad del servicio sin paralizar al equipo. La clave es hacerlo lo suficientemente liviano para que el equipo lo adopte voluntariamente.

GitOps como mecanismo de control de cambios

Concepto tradicionalEquivalente GitOps
RFC Request for ChangePull Request con descripcion del cambio
Revision del CABCode Review en el PR por el equipo
Aprobacion del cambioMerge del PR tras aprobacion de revisores
Ejecucion del cambioPipeline CI/CD ejecutado automaticamente
Registro de cambiosHistorial de commits en git
Auditoriagit blame y git log con autor y timestamp

Ventanas de mantenimiento

  • Produccion: martes y jueves de 22:00 a 23:30 UTC
  • Staging: cualquier dia habil de 14:00 a 17:00 UTC
  • Emergencias: cualquier momento con aprobacion de CTO documentada
  • Freeze de cambios: 24 diciembre al 2 enero excepto P1 y P2
Comunicacion proactiva

Notifica los cambios programados con 24h de anticipacion en Slack: que cambia cuando cuanto dura y quien es el punto de contacto. Esto elimina el 80% de la friccion interna.

Capitulo 5

Auditoria digital automatizada en cloud

La auditoria continua reemplaza a la auditoria anual puntual. Con las herramientas correctas conoces el estado de cumplimiento en tiempo real.

Herramientas de auditoria cloud

HerramientaQue auditaSalidaFrecuencia
AWS ConfigConfiguracion de recursos AWSDashboard y alertasContinuo
AWS Security HubHallazgos de seguridad consolidadosDashboard y SIEMContinuo
ProwlerMas de 500 controles de seguridad AWSHTML CSV JSONSemanal
CloudTrail + AthenaHistorial completo de API callsSQL queriesPor incidente
terraform planDrift entre codigo y estado realCLI outputAntes de cada deploy
ScoutSuitePostura de seguridad multi-cloudHTML interactivoMensual

Activacion rapida de Security Hub

bash - activar Security Hub con CIS Benchmark
# Activar Security Hub
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

# Ver findings criticos activos
aws securityhub get-findings \
  --filters '{
    "RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}],
    "SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]
  }' \
  --query 'Findings[].{Title:Title,Resource:Resources[0].Id}' \
  --output table

# Escaneo completo con Prowler
docker run -ti --rm \
  -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY \
  prowler/prowler:latest aws \
  --output-formats html,csv \
  --output-directory /tmp/prowler

Capitulo 6

Marcos de cumplimiento normativo en cloud

El cumplimiento no es un destino; es un estado continuo que se mantiene con procesos automatizados y revisiones periodicas.

Mapa de controles cruzados

Control implementadoISO 27001SOC 2NIST CSFISO 20000
Gestion de accesos IAM con MFAA.5.17CC6.1PR.AC-77.2
Logging centralizado e inmutableA.8.15CC7.2DE.AE-38.2
Control de cambios documentadoA.8.32CC8.1PR.IP-39.2
Backup verificado con pruebasA.8.13A1.2PR.DS-110.1
Gestion de vulnerabilidadesA.8.8CC7.1ID.RA-18.3
Gestion de proveedoresA.5.19CC9.2ID.SC-27.3

Hoja de ruta de certificacion ISO 27001 en 12 meses

MesActividadEntregable
1-2Gap analysis estado actual vs requisitos ISOInforme de brechas priorizado
3-4Implementar controles criticos faltantesControles documentados y operativos
5-6Documentar SGSI alcance politica y SoADocumentacion del sistema de gestion
7-8Auditoria interna simular la certificacionInforme de auditoria interna
9Remediar hallazgos de la auditoria internaPlan de acciones correctivas cerrado
10-12Auditoria de certificacion Stage 1 y 2Certificado ISO 27001:2022
Costo real

Una certificacion ISO 27001 para PYME de 10-50 personas cuesta entre 15000 y 40000 USD con consultora. Sin consultora entre 5000 y 15000 USD con documentacion de calidad.

Capitulo 7

Tableros de mando y reporting operativo

El reporting transforma datos tecnicos en decisiones de negocio. Un informe bien estructurado es tan valioso como cualquier otro entregable tecnico.

Los tres niveles de reporting

NivelAudienciaFrecuenciaContenidoLectura
OperativoEquipo tecnicoDiario o semanalMetricas incidentes activos y deploys5 min
TacticoIT Manager y Tech LeadsSemanal o mensualKPIs por area avance de proyectos y riesgos15 min
EstrategicoCTO CEO y DireccionMensual o trimestralEstado del negocio tech inversion y roadmap30 min

Plantilla de informe mensual

markdown - informe mensual TI
# Informe Mensual de TI - Mayo 2026
Preparado por: [Nombre] | Fecha: [fecha]

## Estado general
VERDE Operaciones: NORMAL | AMARILLO Seguridad: ATENCION

## KPIs del mes
| Metrica           | Objetivo  | Real  | vs Anterior |
|-------------------|-----------|-------|-------------|
| Uptime servicios  | >=99.5%   | 99.7% | +0.2%       |
| MTTR incidentes   | <=4h      | 2.3h  | -0.8h       |
| Frecuencia deploy | >=2/semana| 3.2   | +0.4        |
| Cobertura backup  | 100%      | 100%  | sin cambio  |

## Top 3 logros
1. Tiempo de deploy reducido de 45 a 12 minutos
2. MFA implementado para todos los usuarios cloud
3. 10 runbooks criticos documentados

## Riesgos activos
| ID  | Riesgo           | Estado      |
|-----|------------------|-------------|
| R02 | IAM sin revision | En progreso |

## Proximo mes
1. Remediar IAM - Kevin - 15 junio
2. Prueba DR trimestral - Equipo Ops - 20 junio

Capitulo 8

Gestion del conocimiento y documentacion tecnica

La documentacion no es un lujo; es infraestructura. Un equipo sin documentacion tiene bus factor de 1.

Tipos de documentacion y su proposito

TipoPregunta que respondeCuando actualizar
RunbookComo ejecuto esta tarea paso a paso?Ante cada cambio en el proceso
ADR Architecture Decision RecordPor que tomamos esta decision tecnica?Al tomar cada decision arquitectonica
Diagrama de arquitecturaComo estan conectados los sistemas?Ante cambios de arquitectura
Playbook de incidentesQue hago cuando X falla?Tras cada post-mortem con gaps
Guia de onboardingComo soy productivo en 48h como nuevo ingreso?Trimestral

Architecture Decision Record ADR

markdown - plantilla ADR
# ADR-042: Usar Terraform para infraestructura AWS

Estado: Aceptado | Fecha: 2026-03-15
Decisores: CTO, Architect, DevOps Lead

## Contexto
Necesitamos gestionar infraestructura cloud de forma reproducible.
Actualmente se usa la consola AWS generando inconsistencias entre entornos.

## Decision
Adoptaremos Terraform como herramienta de IaC para toda la
infraestructura AWS nueva. La infraestructura existente se migrara
progresivamente durante Q2 2026.

## Alternativas consideradas
- AWS CloudFormation: descartado por sintaxis verbosa y menor flexibilidad.
- Pulumi: descartado por menor madurez del ecosistema.

## Consecuencias positivas
- Infraestructura reproducible entre todos los entornos
- Historial de cambios en git con revision via PR
- Tiempo de aprovisionamiento reducido a minutos

## Consecuencias negativas
- Curva de aprendizaje inicial de 2-3 semanas por persona
Onboarding

Prueba simple: puede un nuevo ingreso ser productivo en 48h sin preguntar constantemente? Si la respuesta es no la documentacion es insuficiente.

Capitulo 9

Implementacion hoja de ruta y apendices

La implementacion de este framework es un proyecto con fases claras. No intentes implementarlo todo a la vez; el cambio organizacional necesita tiempo.

Plan de 90 dias - quick wins

SemanaFocoEntregable concreto
1-2Diagnostico y priorizacionEvaluacion de madurez completada; top 5 brechas identificadas
3-4RACI y rolesRACI de 20 funciones clave; roles documentados
5-6Politicas criticas3 politicas redactadas aprobadas y comunicadas
7-8Control de cambiosProceso activo; primeras RFC registradas
9-10KPIs y dashboardDashboard con 6 KPIs; primer informe mensual
11-12Revision y ajusteSegunda evaluacion de madurez; plan Q2 definido

Herramientas recomendadas por area

AreaHerramientaAlternativaCosto
Documentacion tecnicaNotion / ConfluenceGitHub Wiki0-10 USD por usuario
Gestion de incidentesPagerDuty / OpsGenieSlack mas runbooks0-20 USD por usuario
Control de cambiosGitHub / GitLabJira mas Confluence0-15 USD por usuario
KPIs y dashboardsGrafana mas CloudWatchPower BI / Looker0-9 USD por usuario
Auditoria cloudProwler mas Security HubCloudSploit0-500 USD por mes
Mensaje final

La gobernanza tecnologica no es un proyecto que termina; es una practica que madura. Cada trimestre que implementas consistentemente estos procesos el equipo se vuelve mas eficiente y la organizacion mas preparada para crecer.