
Evaluación de proveedores de software. Seguridad y propiedad
Una lista de verificación sobre seguridad, integraciones, roles de datos, propiedad, soporte y salida antes de firmar un contrato de software.
No elija un socio por una presentación ni por la oferta más baja. Elija un equipo que comprenda el problema, pueda mostrar trabajo comparable y asuma la responsabilidad del resultado, la seguridad y la entrega. En software, automatización, diseño o modernización, una propuesta es solo una hipótesis. Compruébela con evidencias.
El estudio de 6sense de 2025 indica que los grupos compradores suelen ordenar su shortlist antes del primer contacto. Gartner informó en 2025 que el 61 por ciento de los compradores B2B prefiere una experiencia general de compra sin representante. Llegue a la conversación con criterios propios. El contexto está en el comunicado de Gartner.
Antes del RFP describa la decisión que el sistema debe mejorar. Quién trabaja manualmente hoy, de dónde vienen los datos, qué error cuesta dinero y qué mostrará el cambio después del lanzamiento. Defina los límites de alcance, un propietario interno, presupuesto, fecha y dependencias. Escriba también lo que la solución no debe hacer.
El RFP no tiene que ser largo. Los mismos requisitos, escenarios de usuario, integraciones, acceso a datos, modelo operativo y forma de aceptación dan a cada proveedor una base equivalente.
Elija entre tres y cinco candidatos. Anote evidencias, no impresiones. Registre cómo entiende cada equipo el proceso, quién hará el trabajo, qué problema parecido entregó, qué queda incierto y qué debe responder el discovery.
En una pantalla pequeña, desplace la tabla horizontalmente.
| Criterio | Evidencia | Peso |
|---|---|---|
| Comprensión del problema | Resumen escrito de proceso y riesgos | 20 |
| Entrega y propiedad | Equipo, hitos, repositorio, traspaso | 20 |
| Arquitectura y operación | Decisiones, pruebas, monitorización, soporte | 20 |
| Seguridad y datos | Accesos, contrato, incidentes, copias | 20 |
| Precio y TCO | Supuestos, cambios, costes operativos | 20 |
Un socio creíble no finge una respuesta exacta antes de conocer el problema. Documenta supuestos, preguntas abiertas, riesgos y el resultado del discovery. La estimación separa el trabajo confirmado de la reserva. Pregunte quién dirige los talleres, cómo se toman las decisiones y qué recibirá si no continúa después del discovery.
Aclare la responsabilidad sobre backlog, calidad, despliegue y soporte tras el traspaso. Pregunte dónde vivirán los datos, cómo se gestionan los accesos, cómo se prueban los cambios, quién observa los fallos y cómo se restaura el servicio tras un incidente. Pida un ejemplo de pruebas, un ejemplo anonimizado de release y un plan operativo.
Acuerden la propiedad del código fuente, diseños, cuentas, dominios, tenant de cloud y licencias. Nombre un administrador de cuentas y un procedimiento para retirar acceso. El contrato debe cubrir confidencialidad, datos personales, subcontratistas, aviso de incidentes, copias, documentación y traspaso al terminar el trabajo.
El NCSC aconseja a los clientes pedir evidencias de las afirmaciones de seguridad del proveedor y mantener la comprobación en el tiempo. La guía de NIST incluye verificación de software, vulnerabilidades y componentes en el riesgo de cadena de suministro. Ajuste las preguntas al riesgo real del sistema.
Compare el mismo alcance. El presupuesto debe indicar discovery, implementación, pruebas, despliegue, licencias, cloud, soporte y solicitudes de cambio. El TCO no es solo el primer release. Incluye operación, tiempo interno, formación, mantenimiento, coste de cambio y riesgo de una mala integración.
Si el alcance es incierto, use un piloto pagado. Debe tener un objetivo limitado, criterios de aceptación medibles, acceso a los datos necesarios y una decisión clara al terminar. Un piloto no es un prototipo barato sin propietario.
En cada referencia pregunte por el contexto, papel del proveedor, problema, alcance, resultado y relación de trabajo. Si es posible, hable con el cliente sin el proveedor. Puntúen los candidatos por separado antes de la reunión conjunta. Después comparen las diferencias entre operación, finanzas, seguridad y las personas que usarán el sistema.
Las señales de alerta son alcance indefinido, presión para firmar, estimación sin supuestos, propiedad poco clara, pruebas ausentes, soporte sin definir y una referencia sin contexto verificable. Antes de seleccionar, confirmen el problema, criterios, presupuesto, riesgos, propietario de la decisión y plan de los primeros 90 días.
Revise el proceso, el catálogo de servicios, la seguridad, los precios y las condiciones. Use la calculadora, prepare la matriz y lea más guías de decisión en el blog. Después invite a la shortlist al discovery compartido.

Una lista de verificación sobre seguridad, integraciones, roles de datos, propiedad, soporte y salida antes de firmar un contrato de software.

Cree un caso de negocio para software o automatización a partir del coste medido del proceso actual, TCO, escenarios, sensibilidad y criterios de parada.

Explicamos de forma práctica la semántica, el teclado, el foco, el contraste, los formularios, el reflow, el movimiento reducido y los límites de las pruebas automáticas en Rise.sk.