Respuesta y comunicación
Quién actúa, con qué runbook y con qué escalamiento, y cómo se informa a la organización, a los clientes y al regulador.
Continuidad · Seguridad de la información · Gobierno de IA
Preparo a las organizaciones para seguir operando cuando llegue el incidente, y para demostrarlo.
Una certificación prueba que el sistema existe. Solo la operación prueba que funciona. Diseño e implemento sistemas de continuidad y de seguridad de la información, y los pruebo con el equipo que va a responder. En gobierno de IA diseño y dicto programas ejecutivos.
Cámara de Bancos e Instituciones Financieras de Costa Rica
Formación ejecutiva
IBEE
Cofundador y Director Académico
Universidad de Belgrano, USAL y UBA
Docencia universitaria
Enfoque
Un plan de continuidad que nunca se probó es solo un documento.
Un cliente grande, un auditor o un regulador piden hoy evidencia de que el servicio crítico sigue operando cuando algo falla. Esa evidencia sale de probar el plan con el equipo que va a responder. Recuperación y operación degradada son los frentes que un ejercicio cómodo deja afuera, y los que decidieron cuánto tardó Delta Air Lines en recuperarse en julio de 2024.
Redundancia
Si la redundancia declarada existe y cubre el servicio, o si varios proveedores del registro dependen en realidad de la misma nube.
Recuperación
En cuánto tiempo vuelve el servicio frente al tiempo que la organización comprometió.
Operación degradada
Cómo se sigue operando con una parte de los servicios caídos, que es el estado real de las primeras horas.
Trayectoria
Mario Pettersen
Consultor y educador ejecutivo en Buenos Aires. Desde 2018 ejerzo con el nombre comercial PETTERSEN, en continuidad del negocio, seguridad de la información y gobierno de IA, con organizaciones de América Latina y Estados Unidos. Con directorio y comité trabajé en Argentina y República Dominicana. Soy cofundador y Director Académico de IBEE y Consultor Asociado de RiskOff.
20+
años en gobierno de TI, seguridad de la información y riesgo
2018
práctica propia con el nombre comercial PETTERSEN
IBEE
cofundador y Director Académico
Marcos de referencia
- ISO 22301
- ISO 27001
- ISO 42001
- ISO 31000
- ISO 27701
- DORA
- NIST CSF
- SOC 2
- COBIT
Antecedente
- TOGAF
- ITIL
- PMBOK
- COSO ERM
Credenciales y antecedentes
Certificaciones PECB
- ISO 31000 Lead Risk ManagerPECB · 2020
- Lead Cloud Security ManagerPECB · 2021
- Lead SOC 2 ManagerPECB · 2024
- ISO 37001:2025 TransitionPECB · 2025
- ISO/IEC 27001:2022 FoundationPECB · 2023
- Certified Artificial Intelligence ManagerCurso PECB · 2026
Formación académica
- Licenciado en Sistemas de InformaciónUniversidad de Belgrano · 1987
- Posgrado en Gestión de ProyectosUniversidad de Belgrano · 2000
- Especialista en Seguridad InformáticaCentro de Capacitación en Alta Tecnología · 2001
Docencia universitaria
- Universidad de Belgrano, Facultad de TecnologíaDe asistente técnico a profesor adjunto · 1986-1990
- Universidad del SalvadorDe ayudante a profesor titular de Sistemas de Información I · 1987-1990
- Universidad de Buenos Aires, Facultad de Ciencias EconómicasProfesor auxiliar de Tecnología de la Información · 2007-2010
Formación ejecutiva
- Cámara de Bancos e Instituciones Financieras de Costa RicaProgramas para directores y gerentes de la banca · 2025-2026
- IBEECofundador y Director Académico · desde 2020
Documentación a pedido
Para un alta de proveedor envío la constancia de inscripción en ARCA, diplomas y certificados, y una ficha con identidad legal y forma de prestación.
Servicios
Frentes distintos, un mismo criterio de decisión.
01
Prueba de preparación ante incidentes
Una prueba sobre un servicio piloto: cómo responde y se comunica el equipo, qué redundancia existe, cómo se recupera el servicio y cómo se opera con servicios caídos. Aproximadamente un mes. Queda un informe con la evidencia de lo que funciona y de lo que falta.
Agendar la sesión de alcance02
Continuidad y seguridad de la información
Diseño e implemento los sistemas con ISO 22301 e ISO/IEC 27001. Las brechas las cierra el equipo de la organización, el proveedor que elija o yo. Si las cierro yo, la prueba siguiente la valida un tercero que elija la organización. No armo un sistema de gestión solo para pasar la auditoría: si no se va a probar, no lo tomo.
03
Gobierno de riesgos e IA
Riesgo no financiero, riesgo de terceros y proveedores críticos, y gobierno de los sistemas de IA que entran por la renovación de contratos de software. Apetito, indicadores y exposición ante el comité.
04
Formación ejecutiva
Programas para organizaciones, del directorio a la alta gerencia, en forma directa y a través de IBEE. Riesgo, gobierno y tecnología explicados para la decisión que toma cada nivel.
ibee.educationCasos
Estructuras que había que rediseñar bajo presión.
Cada uno arranca donde el diseño formal dejó de responder y quien tiene autoridad de decisión necesita rehacer la estructura.
Banca pública de alcance nacional en LATAM. Área de Tecnología de varios cientos de personas.
TOGAF- Presión
- La cartera de pendientes de Tecnología cuadruplicaba el estándar de la industria, con solicitudes que esperaban meses en cola sobre una base de deuda técnica sin plan de reducción. La auditoría lo asentó como observación con remediación comprometida.
- Decisión a sostener
- Un órgano central con autoridad para rechazar demanda de gerencias con poder político propio y para frenar iniciativas ya comprometidas con el negocio. La alternativa disponible era sumar capacidad de ejecución sobre el mismo circuito de entrada, que reproduce la cola con más costo y sin cambiar quién decide.
- Qué se hizo
- Rediseño de la arquitectura de la función de Tecnología con TOGAF: capacidades, flujos de decisión y dependencias entre dominios definidos antes de tocar el circuito de demanda. Sobre esa arquitectura se fijaron criterios de priorización con pesos explícitos, matriz RACI y definiciones de proceso con COBIT, y evaluación de riesgo de cada solicitud con ISO 31000.
- Consecuencia
- Demanda reordenada bajo los nuevos criterios, cartera de pendientes reducida y ciclo de solicitud a decisión llevado a un tercio.
Organización de distribución con red de sucursales y depósitos propios en América Latina.
ISO/IEC 27000 (lineamiento)- Presión
- El stock registrado no coincidía con el físico y la información de gestión llegaba tarde e incompleta, sobre una base tecnológica obsoleta que alargaba cada proceso. La red de sucursales decidía con datos que no soportaban la decisión.
- Decisión a sostener
- Rehacer la organización para que la información tuviera integridad, disponibilidad y confidencialidad verificables, y para que la fuerza de ventas trabajara donde está el cliente. La propuesta alternativa era renovar la tecnología sobre la organización existente: los mismos procesos ejecutados más rápido, con los errores de stock intactos.
- Qué se hizo
- Programa plurianual de rediseño operativo sobre una red de sucursales con operación autónoma y dependencia tecnológica local. La administración se consolidó en una unidad central única, la logística quedó bajo dirección central con el stock consolidado en un registro único sobre los depósitos de distribución, y la fuerza de ventas dejó de tener a la sucursal como lugar de trabajo. Los controles sobre la información se tomaron de la familia ISO/IEC 27000 como lineamiento, sin objetivo de certificación.
- Consecuencia
- La mayor parte de la operación administrativa y comercial pasó a ejecutarse desde cualquier ubicación, sin depender de la sucursal. La presencia física quedó reducida a los depósitos de distribución. La organización más que duplicó su facturación con casi los mismos recursos.
Método
La prueba muestra dónde falla el plan. El nivel de cada falla fija quién decide y con qué plazo.
La prueba corre sobre un servicio piloto, con el equipo que va a responder. Cada falla registrada entra en la matriz de probabilidad por impacto, y su nivel fija la decisión, el escalamiento y la firma. El color nunca decide solo: cada celda lleva su código.
Cómo es la prueba
Servicio piloto
El servicio crítico que mira el cliente o el regulador. El método se extiende después al resto.
Escenario
Incluye la caída de un proveedor y la operación degradada, los frentes que un ejercicio cómodo deja afuera.
Ejercicio de mesa
Prueba la respuesta, la comunicación y los procedimientos con el equipo que responde. La conmutación técnica de sistemas queda fuera del ejercicio.
Informe
Cada falla queda registrada con fecha, escenario y responsable. La organización recibe lo que funciona y lo que falta.
5
MProbabilidad 5, impacto 1. Nivel Medio.
AProbabilidad 5, impacto 2. Nivel Alto.
AProbabilidad 5, impacto 3. Nivel Alto.
CProbabilidad 5, impacto 4. Nivel Crítico.
CProbabilidad 5, impacto 5. Nivel Crítico.
4
BProbabilidad 4, impacto 1. Nivel Bajo.
MProbabilidad 4, impacto 2. Nivel Medio.
AProbabilidad 4, impacto 3. Nivel Alto.
AProbabilidad 4, impacto 4. Nivel Alto.
CProbabilidad 4, impacto 5. Nivel Crítico.
3
BProbabilidad 3, impacto 1. Nivel Bajo.
MProbabilidad 3, impacto 2. Nivel Medio.
MProbabilidad 3, impacto 3. Nivel Medio.
AProbabilidad 3, impacto 4. Nivel Alto.
AProbabilidad 3, impacto 5. Nivel Alto.
2
MBProbabilidad 2, impacto 1. Nivel Muy bajo.
BProbabilidad 2, impacto 2. Nivel Bajo.
MProbabilidad 2, impacto 3. Nivel Medio.
MProbabilidad 2, impacto 4. Nivel Medio.
AProbabilidad 2, impacto 5. Nivel Alto.
1
MBProbabilidad 1, impacto 1. Nivel Muy bajo.
MBProbabilidad 1, impacto 2. Nivel Muy bajo.
BProbabilidad 1, impacto 3. Nivel Bajo.
BProbabilidad 1, impacto 4. Nivel Bajo.
MProbabilidad 1, impacto 5. Nivel Medio.
1
2
3
4
5
- MB Muy bajo
- B Bajo
- M Medio
- A Alto
- C Crítico
| Nivel | Decisión | Escalamiento | Firma |
|---|---|---|---|
| CCrítico | Tratamiento inmediato con plan y fecha de cierre | Directorio, de inmediato: aviso a la presidencia y sesión extraordinaria si hace falta | Directorio |
| AAlto | Tratamiento con plan, responsable y plazo | Comité de riesgos | Comité de riesgos |
| MMedio | Tratamiento o transferencia según costo del control | Alta gerencia | Responsable del riesgo |
| BBajo | Monitoreo con umbral de revisión definido | Informe periódico | Responsable del riesgo |
| MBMuy bajo | Aceptación registrada | Sin escalamiento | Responsable del riesgo |
Publicaciones
Notas para quien decide.
Seguir en LinkedIn- ContinuidadEl incidente va a ocurrir. Lo que el directorio decide es si la organización lo probó antesEl directorio que aprueba un plan de continuidad sin exigir su prueba aprueba un documento. La primera prueba real de ese documento llega con el incidente, delante del cliente.
- Gobierno de IAProveedores de inteligencia artificial: el tercero crítico que falta en el registroEl proveedor de IA que trata datos o decide sobre clientes es un tercero crítico, y el supervisor lee su ausencia en el registro como una falla de control interno.
- RegulaciónPrórroga regulatoria en LATAM: qué se postergó y qué sigue corriendoLos reguladores postergaron sobre todo obligaciones de divulgación y mantuvieron las de capacidad operativa. El inventario de obligaciones y el presupuesto 2027 se ordenan por la forma de cumplimiento.
- Gobierno de IALas obligaciones del AI Act se corrieron a 2027 y el directorio se quedó sin fecha de vencimientoLa prórroga del régimen de alto riesgo deja corriendo la transparencia del artículo 50 y el régimen sancionatorio. El tiempo ganado se usa para armar inventario, clasificación y evidencia.
- ContinuidadResiliencia operativa: Métricas que toman decisionesSin unidad de medida, una tolerancia queda en intención. Las métricas de resiliencia conectan el apetito, las tolerancias y los KRI con la obligación regulatoria.
Contacto
Empecemos por la pregunta correcta.
Una primera conversación sobre el servicio que tiene que seguir operando y ante quién hay que demostrarlo.
Agenda abierta
Elegí un horario directamente sobre mi calendario. Sin intercambio de correos para coordinar.
Reservar una conversación inicial Sesión de alcance de la prueba