Respuesta corta: los stakeholders son las personas cuyo trabajo depende de los sistemas que vas a escanear y parchear: gerencia, dueños de cada aplicación y, según el caso, seguridad física y recursos humanos. Para conseguir su apoyo, hablá de interrupción del negocio y de plazos acordados, y dejá los CVE para el informe técnico. El resultado mínimo es un compromiso escrito: quién autoriza, en qué ventanas se puede parchear y en cuántos días se corrige cada severidad.
La regla: sin acuerdo previo, el primer parche urgente se convierte en una discusión.
Quiénes son los stakeholders
La guía de DHS/CISA (CRR Resource Guide — Vulnerability Management) incluye entre los stakeholders a quienes tienen rol de autorización, a los gerentes y ejecutivos de las unidades donde residen los activos, y aclara que la gestión de vulnerabilidades puede no limitarse a IT. Según el alcance, puede involucrar a seguridad física y a recursos humanos.
En una PyME suele ser una lista corta:
| Stakeholder | Qué le importa | Qué necesitás de esa persona |
|---|---|---|
| Dueño o gerente general | Continuidad del negocio, costo, riesgo legal | Respaldo explícito, presupuesto, decisión sobre riesgos aceptados |
| Responsable de cada sistema (administración, ventas, producción) | Que su área siga trabajando | Aprobar ventanas de cambio y plazos para su sistema |
| Proveedor externo o integrador | Su contrato y su responsabilidad | Que cumpla los plazos y reporte lo que parchea |
| Recursos humanos | Altas, bajas, capacitación | Sumarse a la capacitación y a los procedimientos de alta y baja de usuarios |
| Responsable de instalaciones | Acceso físico a la sala de servidores | Control de acceso al equipamiento |
Cada empresa agrega o saca filas. Lo importante es que todos los sistemas del alcance tengan un dueño con nombre.
Qué dice la guía que deben hacer
La fuente define tres responsabilidades de los stakeholders:
- Aportar los requisitos particulares de su unidad.
- Promover el plan entre sus equipos.
- Acordar los plazos de remediación.
El tercer punto es el que más trabajo da, y el más valioso. Un plazo acordado de antemano ("críticas en tantos días, altas en tantos") te evita negociar caso por caso, y le da a cada responsable previsibilidad. Los plazos concretos los fija tu plan y política; esta semana se trata de conseguir que los firmen quienes tienen que cumplirlos.
Cómo hablarle a gerencia
Gerencia necesita decidir tres cosas: cuánto tiempo del técnico se dedica, qué riesgo se acepta y cuándo se tolera una interrupción. Para decidir bien, le sirve información en términos de negocio:
| En lugar de decir | Decí |
|---|---|
| "Hay hallazgos con CVSS alto en varios servidores" | "Hay fallas que los atacantes están usando hoy, en el firewall y en el servidor de archivos. Arreglarlas implica un corte corto un sábado" |
| "Necesitamos un escáner" | "Hoy no sabemos qué está desactualizado. Con una herramienta gratuita y unas horas por semana lo sabemos y lo corregimos antes de que alguien lo explote" |
| "El parche puede romper el ERP" | "Si parcheamos sin probar, el ERP puede quedar fuera de servicio. Necesitamos una ventana y un respaldo" |
Los números que presentes tienen que ser tuyos y verificables: activos inventariados, cuántos hallazgos están en KEV, cuántos superaron el plazo. Las cifras externas de costo de incidentes sirven poco si no las podés respaldar con una fuente.
Qué pedirle a cada uno
A gerencia:
- Un patrocinante: una persona de nivel directivo que respalde el programa cuando se trabe.
- Horas del técnico asignadas al programa, aunque sean pocas y fijas.
- La decisión explícita de quién acepta los riesgos que no se corrigen.
A los dueños de sistemas:
- Un responsable con nombre y un suplente.
- Una ventana de mantenimiento recurrente para su sistema.
- Aceptar los plazos por severidad, o proponer uno distinto con su justificación.
Al proveedor externo:
- Que acepte por escrito los plazos de parcheo de lo que administra.
- Que reporte los cambios aplicados.
El compromiso por escrito
Una reunión de 20 minutos con la gerencia alcanza si llegás con una propuesta concreta, en lugar de una lista de dudas. Salí de ahí con un acta corta firmada o confirmada por correo, con tres cosas: quién es el patrocinante, qué plazos se aceptan y qué ventanas están reservadas. El lead magnet de este post trae el guion minuto a minuto y una plantilla de acta.
Esa acta apoya los roles definidos en el post sobre roles y responsabilidades, y se retoma en cada revisión del plan.
Preguntas frecuentes
¿Y si la gerencia no quiere invertir tiempo?
Pedí menos y más concreto: 20 minutos, una decisión y un acta de una hoja. Mostrá un hallazgo real de tu entorno que esté en el catálogo KEV. Un caso propio convence más que cualquier presentación general.
¿Un dueño de sistema puede negarse a parchear?
Puede proponer otro plazo o pedir una excepción, pero la decisión de convivir con el riesgo la toma quien responde por el negocio, y se registra con fecha de vencimiento. Quien se opone sin proponer alternativa traslada el riesgo a la gerencia.
¿Hace falta incluir a recursos humanos?
Si tu alcance incluye a las personas (capacitación, altas y bajas de usuarios), sí. Es un stakeholder de menor intensidad, pero necesario.
¿Cada cuánto se vuelve a hablar con ellos?
Con la gerencia, una revisión trimestral corta. Con los dueños de sistemas, cada vez que cambia su sistema o vence un plazo. El post sobre revisión del plan propone un calendario.
En resumen
Identificá a los dueños de cada sistema, hablales en términos de interrupción y riesgo, y conseguí un compromiso escrito sobre patrocinio, plazos y ventanas. Con eso, el primer escaneo del pilar de esta semana se hace con permiso y sin sorpresas.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.