¿Qué debe incluir un contrato de mantenimiento de software?

La propuesta dice “mantenimiento continuo”. Cuando preguntas qué cubre, la respuesta se convierte en “depende del caso”. El sistema sigue siendo importante para ventas, inventario, facturación o atención al cliente, pero el acuerdo no explica quién responde ante un fallo, quién aprueba un cambio o qué ocurre si el proveedor deja de atender a la empresa.

Antes de comparar precios, convierte mantenimiento en preguntas que la empresa pueda comprobar. Si la operación necesita responsabilidad continua sobre el software de la empresa, esa responsabilidad también debe aparecer al hablar de alcance, acceso, decisiones y continuidad.

Este texto es una lista para comprar mejor, no una plantilla legal. La guía de la FTC sobre ciberseguridad para pequeñas empresas, consultada el 27/09/2026, recomienda poner por escrito las expectativas de seguridad en los contratos con proveedores y comprobar que se cumplen. Pide a un profesional que revise las condiciones que creen obligaciones legales en tu jurisdicción.

Respuesta breve

• Define qué sistemas, entornos y procesos están cubiertos.
• Separa mantenimiento, incidentes, dudas, formación y proyectos nuevos.
• Acuerda el canal, la prioridad, el horario y las actualizaciones sin prometer una respuesta que el proveedor no pueda cumplir.
• Mantén las cuentas, los datos y la recuperación bajo control de la empresa, con acceso limitado a lo necesario.
• Exige una forma de transferir el trabajo si el acuerdo termina o la persona que conoce el sistema ya no puede continuar.

¿Qué debe significar “mantenimiento”?

Mantenimiento no es una promesa de hacer cualquier cosa que aparezca. Como mínimo, el acuerdo debe relacionar cada servicio con un sistema, entorno o proceso y describir el resultado esperado. La empresa debe poder mirar una solicitud y decidir si es soporte incluido, corrección, actualización, cambio aprobado o proyecto separado.

Una forma práctica de organizar el alcance es separar:

• Corrección: el sistema hacía algo previsto y dejó de hacerlo.
• Adaptación: cambió una dependencia, un servicio externo o una regla operativa y el proceso necesita un ajuste.
• Prevención y seguridad: actualizaciones, comprobaciones, copias de seguridad, monitorización o revisiones incluidas en el servicio.
• Evolución: una pantalla, integración, informe o regla de negocio nueva que cambia el producto y necesita una decisión propia.

Estos nombres no son una ley ni un estándar obligatorio. Sirven para evitar que “mantenimiento” esconda cuatro trabajos distintos. La guía de NIST sobre cómo formar un equipo de ciberseguridad para pequeñas empresas, consultada el 27/09/2026, recomienda documentar el nivel de servicio, las responsabilidades y las expectativas en un acuerdo formal cuando una empresa externaliza este trabajo.

¿Qué queda dentro y fuera del alcance?

Un alcance comprensible permite que dos personas clasifiquen una solicitud de forma parecida. No tiene que enumerar cada detalle del sistema, pero sí debe nombrar las áreas que suelen causar discusiones: integraciones, datos, infraestructura, proveedores externos, usuarios, informes y cambios de proceso.

Usa esta tabla como guía para conversar, no como una cláusula lista para copiar:

No escribas solo “soporte para todo el software”. Di si el soporte cubre una aplicación creada por el proveedor, un producto comprado, un servicio cloud o una conexión entre empresas. Si el trabajo depende de un tercero, el acuerdo debe explicar qué ocurre cuando ese tercero falla.

¿Cómo debe tratar el acuerdo los incidentes y los tiempos de respuesta?

El tiempo de respuesta no es lo mismo que el tiempo para recuperar el proceso o corregir la causa. El acuerdo resulta más claro cuando separa esas etapas y explica qué recibe la empresa mientras el problema sigue abierto. Sin esa distinción, “responder en X” puede significar solo confirmar que existe un ticket.

Antes de aceptar una tabla de niveles de servicio, comprueba:

1. Canal: ¿dónde se abre un incidente y qué información debe incluir?
2. Prioridad: ¿qué convierte un problema en crítico para la operación y no solo molesto?
3. Horario: ¿el reloj corre solo en horario laboral o también en fines de semana y festivos?
4. Respuesta: ¿el proveedor identifica a la persona responsable y el siguiente paso?
5. Alternativa: ¿existe una forma temporal de mantener ventas, facturación o atención?
6. Actualizaciones: ¿con qué frecuencia recibe noticias la empresa mientras espera?
7. Escalado: ¿quién decide cuándo hace falta otro proveedor o cambiar la prioridad?

No copies los tiempos de otro acuerdo. Un compromiso solo ayuda si el proveedor tiene acceso, contexto y capacidad para cumplirlo. NIST también recomienda aclarar y documentar los niveles de servicio, las responsabilidades y las expectativas cuando se usan servicios externos. El negocio sigue siendo responsable del riesgo operativo aunque externalice parte del trabajo.

¿Quién controla las cuentas y los datos?

El proveedor puede administrar un sistema sin ser el único dueño de las cuentas que mantienen la operación. El dominio, el alojamiento, los repositorios, el correo de servicio, las bases de datos, las herramientas de pago y las consolas de terceros deben estar vinculados a la empresa, con cuentas individuales y acceso revocable.

La FTC recomienda limitar el acceso del proveedor a lo que necesita y durante el tiempo que lo necesita. La misma guía recomienda registrar cómo se usan, comparten, conservan y eliminan los datos. Convierte eso en preguntas sencillas:

• ¿La cuenta pertenece a la empresa o se creó con el correo personal del proveedor?
• ¿Quién puede conceder, revisar y revocar el acceso?
• ¿Dónde están los datos y cómo los exporta la empresa en un formato utilizable?
• ¿El proveedor usa subcontratistas? Si es así, ¿forman parte del camino de acceso?
• ¿Cómo recibirá la empresa el aviso de un incidente de seguridad?
• ¿Qué ocurre con las copias, credenciales y datos cuando termina el trabajo?

La ficha de CISA para evaluar proveedores en pequeñas y medianas empresas, consultada el 27/09/2026, incluye la evaluación de proveedores con acceso crítico a sistemas o datos. No hace falta convertir cada compra en una auditoría enorme. Sí hace falta saber quién puede actuar, sobre qué y bajo qué regla.

¿Cómo separar el mantenimiento de un cambio nuevo?

Una solicitud de soporte empieza a parecer injusta cuando el cliente cree que compró evolución ilimitada y el proveedor cree que vendió solo correcciones. El acuerdo debe poner ejemplos de ambos lados y definir qué ocurre cuando la clasificación no está clara.

Haz una pregunta operativa: ¿la solicitud devuelve el sistema al comportamiento acordado o cambia el trabajo que hace? Reparar una integración que dejó de funcionar puede ser mantenimiento. Añadir una integración para un proceso que nunca estuvo cubierto suele necesitar una decisión de proyecto. Cambiar un campo puede ser pequeño o puede alterar informes, permisos y facturación.

El proceso puede ser corto:

1. La empresa describe el resultado necesario y el proceso afectado.
2. La persona responsable del sistema confirma si es un fallo, una adaptación o una evolución.
3. Si es trabajo nuevo, el proveedor indica alcance, riesgo, esfuerzo y prueba de aceptación.
4. Alguien con autoridad en la empresa lo aprueba antes de comenzar.
5. La entrega deja constancia de qué cambió y cómo comprobar el resultado.

La lista para comparar propuestas de desarrollo de software antes de firmar ayuda cuando una solicitud de soporte se convierte en una entrega con alcance propio. La regla importante es no iniciar trabajo pagado fuera del acuerdo basándose en una conversación vaga.

¿Cómo probar la continuidad antes de firmar?

Lee la cláusula de salida como si el proveedor no pudiera ayudar durante un mes. ¿La empresa sabe quién puede entrar en las cuentas, dónde están los datos, cómo mantener el proceso más importante y quién decide la siguiente corrección? Si la respuesta es “se lo preguntaremos al desarrollador”, el acuerdo todavía depende de la memoria de una persona.

Haz una prueba de transferencia con un caso pequeño y seguro. Pide al proveedor que muestre:

• el inventario de sistemas, servicios e integraciones cubiertos;
• dónde están la documentación y el historial de cambios;
• cómo exporta datos la empresa y cómo identifica la versión más reciente;
• cómo se comprueba una copia y se realiza una restauración;
• qué accesos se entregarán, conservarán o revocarán;
• cuánto tiempo hay para transferir contexto, credenciales y trabajo abierto;
• quién sigue siendo responsable de un incidente abierto durante la transición.

El acuerdo también debe explicar qué ocurre con el trabajo en curso, los datos, las copias, la documentación, las licencias, los subcontratistas y los cargos al terminar. No tiene que prometer una salida instantánea. Debe evitar que la empresa descubra el coste de salir justo cuando tiene prisa.

¿Freelancer, agencia o responsable continuo?

El acuerdo no convierte automáticamente a un freelancer en una agencia ni hace responsable del negocio a una agencia. La elección depende del volumen de trabajo, la necesidad de coordinación y quién puede fijar prioridades. La guía sobre quién mantiene el software después del lanzamiento compara estos modelos por acceso, contexto, mantenimiento y transferencia.

Si la empresa necesita una corrección puntual, un proyecto bien definido puede bastar. Si el software participa a diario en ventas, inventario, facturación o atención, el acuerdo debe nombrar la responsabilidad que continúa después de la entrega. Puede quedar en manos de una persona interna, un freelancer o un equipo externo que mantenga el contexto y responda por la evolución acordada.

No elijas por la etiqueta. Pregunta quién estará disponible, quién decide, quién documenta y quién da el siguiente paso cuando cambia la operación.

Preguntas para la negociación

¿El acuerdo necesita un tiempo exacto para cada fallo?

Debe definir cómo se asigna la prioridad, cuándo empieza el reloj, qué respuesta se ofrece y cómo se actualiza el incidente. Un compromiso de tiempo sin alcance, canal y responsabilidad puede parecer preciso y no decir cuándo volverá a funcionar el proceso.

¿La empresa necesita contratar a una persona técnica interna?

No necesariamente. Aunque no tenga un desarrollador en plantilla, alguien en la empresa debe aprobar prioridades, controlar las cuentas, confirmar el resultado y decidir qué es aceptable para la operación. El proveedor puede hacer el trabajo, pero no debería ser la única persona capaz de explicar el sistema.

¿Un contrato de mantenimiento elimina la dependencia del proveedor?

No. Reduce la ambigüedad cuando define alcance, acceso, registro de cambios, datos, continuidad y salida. La dependencia sigue siendo alta si la empresa no controla las cuentas, no puede exportar sus datos o no tiene forma de transferir el contexto a otra persona.

Conclusión

Antes de firmar un contrato de mantenimiento de software, haz cinco preguntas: ¿qué incluye?, ¿cómo se atiende un fallo?, ¿quién controla el acceso?, ¿cuándo un cambio se convierte en proyecto? y ¿cómo puede salir la empresa? Las respuestas deben estar en el acuerdo y ser comprensibles para quien dirige la operación, no solo para quien escribió la propuesta.

Si la empresa todavía no sabe si necesita un proyecto, soporte continuo o una función interna, compara esa decisión con cuándo debe una pequeña empresa contratar a un desarrollador. Si el problema empezó porque los sistemas no comparten información, consulta el diagnóstico de los sistemas que no se conectan entre sí.

El mantenimiento no consiste solo en reparar lo que se rompe. Es acordar quién cuida el sistema, dónde termina esa responsabilidad y cómo continúa el negocio cuando necesita a otra persona.

Fuentes

• Federal Trade Commission, “Cybersecurity for Small Business”, consultado el 27/09/2026, https://www.ftc.gov/business-guidance/small-businesses/cybersecurity
• National Institute of Standards and Technology, “Building Your Small Business’s Cybersecurity Team”, consultado el 27/09/2026, https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/building-your-team
• Cybersecurity and Infrastructure Security Agency, “Assisting Small and Medium-sized Businesses Assess Vendors and Suppliers Fact Sheet”, consultado el 27/09/2026, https://www.cisa.gov/resources-tools/resources/assisting-small-and-medium-sized-businesses-assess-vendors-and-suppliers-fact-sheet