Respuesta corta: la gestión de vulnerabilidades necesita tres funciones: detectar (monitorear fuentes y escanear), corregir (aplicar parches o mitigaciones) y autorizar (aprobar el cambio y aceptar riesgos). En una PyME con uno a tres técnicos, una persona puede cubrir las dos primeras. conviene que la autorización la dé otra persona, y para los casos urgentes hace falta un camino de cambio de emergencia escrito de antemano.
La regla: cada tarea del proceso tiene un nombre propio, y quien autoriza no es quien ejecuta.
Los tres roles de la guía de CISA
La guía de DHS/CISA (CRR Resource Guide — Vulnerability Management) agrupa las funciones en tres roles:
| Rol | Qué hace | Quién lo cubre en una PyME |
|---|---|---|
| Monitoreo | Lee las fuentes de información, evalúa si la vulnerabilidad aplica, la anota en el registro y avisa a quien corrige | Técnico de IT o proveedor externo |
| Remediación | Analiza el impacto del parche, prepara una alternativa si no hay parche, pide autorización del cambio y abre la gestión de riesgo si el plazo se vence | Técnico de IT |
| Autorización | Conoce el sistema, revisa si el cambio puede afectarlo, y aprueba, posterga o rechaza | Dueño del sistema o de la unidad de negocio |
Sobre el tercer rol la guía agrega algo que se saltea con frecuencia: debe existir un proceso de cambio de emergencia para las correcciones que no pueden esperar.
Por qué separar la autorización
Cuando el técnico que descubre el problema también decide si se aplica el cambio, nadie contrasta su criterio con el negocio. Un parche en el servidor de facturación puede ser correcto técnicamente y caer el último día del mes. Quien conoce ese calendario es el dueño del sistema.
En una empresa chica, esa separación se consigue sin burocracia: el técnico propone, el responsable del área aprueba por escrito (un mensaje alcanza, mientras quede registrado) y la gerencia resuelve las excepciones.
RACI para un equipo chico
RACI asigna a cada actividad cuatro posibles letras: R (hace), A (responde por el resultado, una sola persona), C (se la consulta) e I (se la informa). Para una empresa con dos técnicos:
| Actividad | Técnico IT | Dueño del sistema | Gerencia |
|---|---|---|---|
| Leer fuentes y registrar vulnerabilidades | R/A | I | I |
| Ejecutar el escaneo | R/A | C | I |
| Aplicar el parche | R | A | I |
| Aprobar la ventana de cambio | C | A/R | I |
| Aceptar un riesgo que vence el plazo | C | R | A |
| Verificar con un reescaneo | R/A | I | I |
Cada fila tiene un solo A. Si dos personas responden por lo mismo, en la práctica no responde ninguna. El lead magnet trae una matriz completa y editable, con una columna para el proveedor externo.
El cambio de emergencia
Algunas vulnerabilidades no esperan a la ventana mensual. Un ejemplo típico: aparece en el catálogo KEV una falla de tu firewall, que tiene el puerto de administración abierto a internet. El camino normal de cambios tarda días. El de emergencia tiene que ser corto, pero no inexistente:
- El técnico documenta en el registro qué falla es, qué activo, y por qué no puede esperar.
- Una persona con autoridad aprueba, con un mensaje o llamada que quede anotada. Se define de antemano quién es y quién lo reemplaza.
- El técnico toma un respaldo o snapshot antes de tocar nada.
- Se aplica el cambio, se prueba el servicio y se avisa a los usuarios afectados.
- Dentro de los días siguientes se completa el registro y se revisa qué se puede mejorar.
El proceso de emergencia se define cuando hay calma. Si se improvisa en medio del incidente, se saltea la aprobación y el respaldo, que son los dos pasos que evitan que el arreglo cause otro problema. Los plazos por severidad, que determinan qué se considera emergencia, se definen en el plan y la política de vulnerabilidades.
Errores típicos
- Roles asignados a un área y no a una persona. "IT se encarga" no identifica a nadie.
- Sin suplente. Cuando el único técnico se va de vacaciones, el proceso se detiene. Anotá un reemplazo para cada rol.
- Proveedor externo sin rol definido. Si un tercero administra parte de la infraestructura, figura en la matriz con qué hace y qué reporta.
- Aceptar riesgos sin firma. Una excepción sin responsable ni fecha de vencimiento se convierte en una vulnerabilidad permanente.
Preguntas frecuentes
¿Y si en mi empresa hay una sola persona de IT?
Esa persona cubre monitoreo y remediación. La autorización tiene que recaer en alguien del negocio: el dueño, el gerente o el responsable del área. El registro escrito compensa la falta de un segundo técnico.
¿Quién acepta un riesgo?
Quien responde por el negocio que depende del sistema, normalmente la gerencia o el dueño. El técnico informa el riesgo, y la decisión de convivir con él es de quien asume sus consecuencias.
¿Hace falta un comité de cambios?
En una PyME suele alcanzar con una persona que aprueba y un registro simple. El comité formal se justifica cuando hay muchos sistemas y varios equipos.
¿El proveedor externo puede ser parte del esquema?
Sí. Se lo incluye en la matriz con sus responsabilidades puestas por escrito en el contrato o en un anexo de servicio.
En resumen
Tres funciones, un responsable por actividad, la autorización separada de la ejecución y un camino de emergencia escrito antes de necesitarlo. Completá la matriz con los nombres de tu empresa y revisá que cada fila tenga una sola A. El pilar de la semana muestra cómo estos roles se ponen en juego en el primer escaneo, y el post sobre stakeholders explica cómo conseguir el apoyo de quienes autorizan.
3 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.