Qué definir en el mantenimiento y la transferencia de software

Separa correcciones, operación y nuevas capacidades

Un canal para consultar no equivale a disponibilidad permanente. Una corrección no necesariamente incluye una función nueva. Revisa que estas categorías aparezcan en la propuesta con sus condiciones, dependencias y exclusiones.

Desliza la tabla si no ves todas las columnas.

Asigna responsabilidades entre empresa y proveedores

Una responsabilidad compartida necesita un punto de coordinación. Si una falla pasa entre proveedores, registra quién conserva el seguimiento, qué evidencia recibe cada parte y quién comunica el estado al equipo de negocio.

• Negocio: persona que confirma el impacto y valida que la operación vuelve a funcionar.
• Aplicación: equipo autorizado para diagnosticar, modificar y publicar cambios.
• Infraestructura: responsable de alojamiento, cuentas, capacidad y accesos.
• Integraciones: contacto y acciones posibles cuando falla una plataforma externa.
• Datos: responsable de autorizar consultas, recuperación y correcciones.
• Decisiones: quién aprueba una intervención urgente y quién puede aceptar un riesgo pendiente.

Diferencia recepción, respuesta y recuperación

Confirmar que se recibió una solicitud, comenzar a revisarla y recuperar el servicio son hitos distintos. Los tiempos y horarios deben acordarse según el impacto, las dependencias y la capacidad contratada. La propuesta debe explicar cómo se clasifica una incidencia y qué información necesita el equipo para actuar.

Describe el impacto con hechos: qué tarea no se puede completar, a cuántos usuarios conocidos afecta y si existe una alternativa temporal. La prioridad debe tener criterios compartidos; marcar toda solicitud como urgente hace más difícil ordenar el trabajo.

• Canal de ingreso y datos mínimos para reportar una falla.
• Horario de cobertura y tratamiento de solicitudes fuera de ese horario.
• Criterios de impacto y prioridad, con ejemplos acordados.
• Condiciones de respuesta, seguimiento y escalamiento.
• Dependencias que pueden afectar la resolución, incluidos accesos y proveedores externos.
• Confirmación por el responsable de negocio antes de cerrar el incidente.

Comprueba que el respaldo permite recuperar lo necesario

Define qué datos, archivos y configuración se respaldan, con qué frecuencia, durante cuánto tiempo y quién puede recuperarlos. Acuerda cuánta información podría perderse desde el último punto recuperable y cuánto tiempo de interrupción tolera el proceso. Esos objetivos necesitan una arquitectura y una prueba compatibles.

La guía StopRansomware de CISA recomienda copias críticas cifradas y fuera de línea, junto con pruebas de disponibilidad e integridad en escenarios de recuperación. Es una referencia para discutir resiliencia; el diseño aplicable depende de los sistemas y de los riesgos de tu operación.

• Comprobar una recuperación en un entorno autorizado, sin sobrescribir producción durante la prueba.
• Verificar datos, archivos y configuración que necesita el recorrido prioritario.
• Registrar el punto recuperado, el resultado y las diferencias encontradas.
• Identificar permisos y claves necesarios para recuperar, conservados por los canales correspondientes.
• Asignar a quien decide cuándo iniciar una recuperación y quien acepta su resultado.

Conserva una relación entre versión, cambio y aceptación

Cada cambio debería permitir identificar qué se modificó, cómo se validó, quién autorizó su publicación y qué versión quedó operando. Define también cómo se vuelve a una versión previa cuando sea técnicamente posible y qué cambios de datos requieren un tratamiento distinto.

NIST SSDF 1.1 propone conservar de forma protegida los archivos y datos de soporte de cada entrega de software. Esto sirve como referencia para discutir la evidencia que se mantiene por versión; mencionarlo no acredita una certificación o conformidad del proyecto.

Prepara la transferencia mientras el software está en operación

Mantén instrucciones de despliegue y recuperación, inventario de servicios, dependencias e integraciones y una lista de pendientes conocidos. Para comprobar la transferencia, el equipo receptor debe poder ejecutar los recorridos acordados con material y accesos autorizados.

OWASP distingue creación, rotación, revocación y expiración de secretos. Cambiar de proveedor requiere revisar ese ciclo y las dependencias de cada acceso, además de compartir documentación. No publiques credenciales ni las incluyas en el acta de transferencia.

• Repositorio o paquete, versión de producción y documentación vigente.
• Administradores y responsables de cuentas, dominios e infraestructura.
• Accesos necesarios y secuencia para sustituir o retirar los que correspondan.
• Servicios de terceros, costos recurrentes y contactos responsables.
• Pruebas del recorrido, respaldo y recuperación acordados.
• Período y condiciones del acompañamiento a la recepción, si se contrata.

Descarga una matriz de continuidad y responsables

Completa cada responsabilidad y deja marcadas las condiciones que todavía requieren acuerdo. Usa referencias a documentación interna autorizada; no copies secretos o datos personales en estas plantillas.

Alcance y referencias de esta guía

Las referencias aportan criterios técnicos para conversar sobre continuidad. No determinan por sí solas cobertura, precios, tiempos de atención o condiciones contractuales. Esos puntos se definen para el proyecto y los recursos que lo sostienen.

Guía institucional de Digital Dev elaborada con asistencia de IA. Las matrices, ejemplos y plantillas son criterios propios para evaluar un proyecto; las referencias técnicas se identifican en esta página.