Un software online puede funcionar durante mucho tiempo con una persona que conoce sus pantallas, reglas y excepciones de memoria. El problema aparece cuando esa persona no está disponible, cambia de función o deja la organización: una tarea rutinaria puede convertirse en una interrupción urgente, y un cambio pequeño puede parecer demasiado arriesgado.
La solución no es documentar cada detalle ni crear una burocracia que frene el trabajo. Es dejar accesible el conocimiento necesario para operar, corregir y mejorar el sistema. Esta guía propone un método práctico para reducir la dependencia de una sola persona.
Qué significa que el mantenimiento dependa de alguien
La dependencia no se mide solo por quién escribe el código. También existe cuando una persona es la única que sabe cómo restaurar un acceso, dónde revisar un error, qué integración no debe tocarse o a quién avisar ante una caída. Si el equipo no puede completar una tarea habitual sin preguntarle, existe conocimiento concentrado.
El marco SSDF de NIST organiza prácticas de desarrollo seguro en torno a preparación, protección, producción y respuesta ante vulnerabilidades. No prescribe un único procedimiento para todas las organizaciones; ofrece un marco que debe adaptarse al contexto. La idea editorial que aplicamos aquí es sencilla: una operación mantenible necesita responsabilidades y procedimientos comprensibles, además de tecnología.
Empezá por las tareas que no pueden quedar bloqueadas
No intentes documentar el sistema entero de una vez. Hacé una lista de tareas que, si nadie sabe hacerlas, podrían detener una operación importante o retrasar la respuesta a un problema. Por ejemplo:
- Dar de alta o quitar accesos y revisar quién tiene permisos administrativos.
- Detectar si el sistema está disponible y dónde consultar errores relevantes.
- Publicar un cambio y comprobar que el servicio sigue funcionando.
- Contactar al proveedor de una integración o escalar un incidente.
- Restablecer una configuración conocida o iniciar una recuperación aprobada.
- Responder a una actualización de seguridad o a una vulnerabilidad reportada.
Priorizá según el impacto operativo, la frecuencia y la dificultad para reemplazar el conocimiento. Una tarea poco frecuente, pero crítica y sin alternativa conocida, puede merecer atención antes que una tarea diaria sencilla.
Documentá lo necesario para actuar
Una guía útil contesta preguntas concretas: qué se intenta lograr, quién puede hacerlo, qué necesita antes de empezar, cómo comprobar el resultado y a quién escalar si falla. Evitá incluir contraseñas, claves privadas o datos sensibles en documentos compartidos. Indicá dónde se administran de forma segura, no su contenido.
Para cada procedimiento prioritario, registrá al menos:
- Propósito y alcance: qué tarea cubre y qué casos quedan fuera.
- Responsable principal y suplente: quién ejecuta, quién autoriza y quién recibe avisos.
- Pasos y comprobaciones: instrucciones legibles y una señal para saber si el resultado fue correcto.
- Dependencias: sistemas, proveedores, permisos o personas que deben intervenir.
- Escalamiento: qué hacer si el procedimiento no funciona y cómo registrar lo ocurrido.
- Fecha de revisión: cuándo se verificó por última vez y quién debe actualizarlo.
Usá capturas o diagramas cuando aclaren una secuencia, pero no como sustituto de instrucciones. Una imagen puede quedar desactualizada y, por sí sola, no explica qué hacer ante una excepción.
Separá responsabilidades y prepará reemplazos
Que haya una persona suplente no significa que todas las personas deban tener acceso total. Definí quién puede consultar, cambiar, aprobar y escalar. Mantené los permisos proporcionales a la tarea y revisalos cuando cambien las funciones del equipo.
Probá la documentación con alguien que no la haya escrito. Pedile que complete una tarea segura en un entorno apropiado y anotá dónde duda. Esta prueba descubre instrucciones implícitas, permisos que faltan y pasos que solo existían en la memoria del autor. En sistemas con entornos separados, no uses producción para experimentar: las guías de NIST incluyen separar y proteger los entornos de desarrollo, prueba y producción como parte de las prácticas de seguridad.
Convertí el mantenimiento en una rutina
Una guía olvidada puede ser tan poco útil como no tener guía. Asigná revisiones breves a momentos que ya existen en el trabajo: una actualización importante, un cambio de proveedor, una rotación de personal o una revisión periódica. Comprobá que los responsables siguen vigentes, que las instrucciones funcionan y que los enlaces a herramientas continúan siendo correctos.
Para organizar cambios y problemas, usá un registro sencillo. Puede ser una herramienta de seguimiento existente. Cada entrada debería indicar el problema o cambio, su prioridad, quién lo atiende, qué se decidió y cómo se comprobó el cierre. NIST recomienda identificar y responder a vulnerabilidades; su material también describe la evaluación, priorización y remediación como actividades que deben organizarse. Eso no significa que toda incidencia tenga la misma urgencia: definí criterios acordes al riesgo y al impacto de tu operación.
Un mantenimiento sólido no depende de que alguien recuerde todo: depende de que el equipo pueda encontrar la información, decidir quién actúa y comprobar el resultado.
Un plan inicial para esta semana
- Elegí tres tareas de mantenimiento cuya interrupción tendría más impacto.
- Nombrá un responsable y un suplente para cada una, con permisos apropiados.
- Escribí pasos breves, criterios de éxito y una ruta de escalamiento.
- Pedile a otra persona que pruebe las instrucciones sin ayuda del autor.
- Corregí los vacíos y fijá una fecha para revisar la guía.
No hace falta convertir un equipo pequeño en un departamento de procesos. Empezá por los puntos donde una ausencia podría detener una tarea importante y ampliá la documentación a medida que cambien el sistema y el trabajo. El objetivo es que otra persona pueda continuar con seguridad, no que todas las personas sepan hacer todo.
Antes de cerrar, comprobá una cosa concreta: si mañana falta quien más conoce el software, ¿qué tarea quedaría bloqueada primero? Documentá esa tarea, asigná un suplente y probá el procedimiento. Ese primer paso transforma un riesgo difuso en una mejora que el equipo puede verificar.
Fuente: Appendix C SSDF Analysis — National Institute of Standards and Technology (NIST), NCCoE
