Software y decisión21 de Septiembre, 2026·11 min de lectura

Cómo evaluar la seguridad de un proveedor de software antes de contratarlo

Una guía práctica para revisar accesos, datos, copias de seguridad, incidentes y subcontratistas antes de contratar software, con preguntas concretas, cláusulas útiles y señales de alerta. Antes de contratar un proveedor de software, no alcanza con mirar funciones, precio y fecha de implementación. La decisión también debe incluir preguntas concretas sobre accesos, datos, copias de seguridad, incidentes y subcontratistas. Una evaluación simple y documentada permite detectar riesgos antes de firmar, comparar propuestas con criterios claros y pedir compromisos útiles sin caer en alarmismo.

DA

Develop Argentina

Develop Argentina

Vendor review table with a printed security questionnaire, a tick-box checklist and a laptop seen from the side.
Software y decisión

Respuesta corta

Evaluá al proveedor en cinco frentes: quién puede acceder a la información, dónde se almacenan los datos, cómo se realizan y recuperan las copias de seguridad, qué ocurre ante un incidente y qué terceros participan del servicio. Pedí respuestas específicas, identificá qué queda escrito en la propuesta y transformá los puntos importantes en cláusulas verificables.

Si la explicación es vaga, cambia entre una conversación y otra o evita responder sobre responsabilidades, tomalo como una señal de alerta. No significa necesariamente que el proveedor sea inseguro, pero sí que la decisión necesita más información antes de avanzar.

Por qué la evaluación debe hacerse antes de contratar

Un proveedor de software puede procesar información de clientes, empleados, operaciones, documentos o credenciales. Aunque la empresa contratante no administre directamente la infraestructura, sigue necesitando entender qué controles existen y quién responde cuando algo falla.

La evaluación previa también evita comparar propuestas únicamente por funcionalidades. Dos soluciones pueden parecer similares, pero diferir mucho en permisos, recuperación de datos, gestión de usuarios o comunicación de incidentes. Esos detalles suelen aparecer tarde, cuando migrar de plataforma ya es costoso o cuando el equipo depende del servicio para trabajar.

El objetivo no es exigir una arquitectura perfecta ni convertir una compra en una auditoría interminable. El objetivo es reducir sorpresas y dejar claras las responsabilidades antes de que el software entre en operación.

Las cinco preguntas que ordenan la conversación

1. Accesos

Preguntá qué perfiles pueden acceder a la información y con qué finalidad. La respuesta debería distinguir entre usuarios de la empresa, personal del proveedor y cuentas técnicas. También conviene consultar cómo se crean, modifican y eliminan permisos, y si existen roles con privilegios elevados.

Preguntas útiles:

  • ¿Qué tipos de usuarios existen y qué puede hacer cada uno?
  • ¿Cómo se revoca el acceso cuando una persona deja de trabajar con la empresa?
  • ¿El proveedor utiliza cuentas individuales o accesos compartidos?
  • ¿Se registra la actividad de usuarios con permisos elevados?
  • ¿La autenticación cuenta con una capa adicional para perfiles sensibles?

Una respuesta sólida describe procesos. Una respuesta débil se limita a decir que el acceso está restringido, sin explicar quién lo controla ni cómo se revisa.

2. Datos

Pedí una explicación clara sobre qué información se almacena, para qué se utiliza y durante cuánto tiempo permanece disponible. También es importante saber cómo se separan los datos de distintos clientes y qué ocurre cuando termina el contrato.

Preguntas útiles:

  • ¿Qué datos necesita realmente el servicio?
  • ¿Qué datos quedan dentro de la plataforma y cuáles se exportan?
  • ¿Cómo se solicita una copia de la información?
  • ¿Cómo se eliminan o devuelven los datos al finalizar la relación?
  • ¿Qué ocurre con los datos incluidos en registros, respaldos o entornos de prueba?

No aceptes una descripción genérica si el proveedor puede explicar el flujo de información con ejemplos. La claridad sobre el recorrido de los datos ayuda a detectar accesos innecesarios y dependencias difíciles de revertir.

3. Copias de seguridad

Una copia de seguridad no es suficiente por sí sola. Hay que entender con qué frecuencia se realiza, cuánto tiempo se conserva y cómo se recupera la información. También conviene preguntar si el proveedor prueba ese proceso o si solo conserva archivos que podrían no servir durante una emergencia.

Preguntas útiles:

  • ¿Qué información se incluye en las copias?
  • ¿Con qué frecuencia se realizan?
  • ¿Cuánto tiempo se conservan?
  • ¿Quién puede restaurarlas?
  • ¿Cómo se verifica que una recuperación funciona?
  • ¿Qué alternativas existen si la plataforma queda temporalmente fuera de servicio?

Evitá promesas absolutas. Una propuesta responsable explica supuestos, límites y pasos de recuperación.

4. Incidentes

Un incidente puede afectar la disponibilidad, la confidencialidad o la integridad de la información. Antes de contratar, preguntá cómo se detectan los problemas, quién coordina la respuesta y de qué manera se informa a la empresa cliente.

Preguntas útiles:

  • ¿Qué consideran un incidente relevante?
  • ¿Quién es el contacto operativo durante una emergencia?
  • ¿Cómo se comunica una interrupción o un acceso no autorizado?
  • ¿Qué información se entrega durante la investigación?
  • ¿Cómo se documentan las medidas posteriores?

La conversación no debería centrarse únicamente en prometer que nunca ocurrirá un problema. Es más útil conocer el proceso previsto para responder, reducir el impacto y aprender de lo ocurrido.

5. Subcontratistas

Algunos proveedores dependen de terceros para alojar información, enviar mensajes, procesar pagos, brindar soporte o mantener componentes técnicos. Esa cadena debe ser visible para que la empresa pueda evaluar dependencias relevantes.

Preguntas útiles:

  • ¿Qué servicios son prestados por terceros?
  • ¿Qué función cumple cada subcontratista?
  • ¿El proveedor informa cambios importantes en esa cadena?
  • ¿Qué controles aplica sobre sus terceros?
  • ¿Quién responde ante una falla de un subcontratista?

Una lista cambiante no es automáticamente un problema. El riesgo aparece cuando no hay transparencia o cuando el contrato no define qué sucede si un tercero cambia las condiciones del servicio.

Tabla de evaluación rápida

ÁreaQué pedirSeñal favorableSeñal de alerta
AccesosRoles, bajas y registrosProcesos claros y responsables definidosAccesos compartidos sin explicación
DatosFlujo, uso y devoluciónInventario comprensible y salida previstaRespuestas vagas sobre conservación
CopiasFrecuencia y recuperaciónPruebas y procedimiento documentadoSolo se menciona que existen respaldos
IncidentesContactos y comunicaciónProceso de respuesta explicadoNo hay canal ni responsable identificable
SubcontratistasFunciones y cambiosCadena visible y gestionadaTerceros desconocidos o sin alcance claro

La tabla no reemplaza una revisión técnica, pero ayuda a ordenar la primera conversación y a comparar proveedores con el mismo criterio.

Checklist antes de firmar

  • Definir qué información ingresará en el software.
  • Identificar quién administrará usuarios y permisos.
  • Solicitar una descripción del proceso de baja de accesos.
  • Preguntar cómo se realizan y prueban las copias de seguridad.
  • Confirmar el canal de contacto para incidentes.
  • Pedir la lista de subcontratistas relevantes.
  • Revisar qué sucede con los datos al finalizar el contrato.
  • Separar las promesas comerciales de los compromisos escritos.
  • Registrar las respuestas importantes junto con la propuesta.
  • Asignar una persona responsable de revisar cambios durante la relación.

Cláusulas útiles para convertir respuestas en compromisos

Las cláusulas deben ser entendibles y adecuadas al servicio contratado. No sirve copiar términos técnicos que nadie pueda comprobar.

Podés pedir que el acuerdo describa el uso permitido de los datos, las responsabilidades sobre usuarios y permisos, el procedimiento de devolución o eliminación de información, y el canal de comunicación ante incidentes. También puede ser útil documentar los servicios de terceros que resulten relevantes, el proceso para informar cambios y las condiciones de colaboración durante una investigación.

En materia de copias de seguridad, el contrato puede indicar qué alcance tiene el respaldo, qué procedimiento se seguirá para solicitar una recuperación y cuáles son los límites del servicio. La redacción debe evitar garantías imposibles de verificar.

Para los incidentes, conviene definir un punto de contacto, la información mínima que se compartirá y la forma de actualizar el estado del caso. El detalle exacto dependerá del tipo de software, de la información involucrada y de la capacidad de cada organización.

Ejemplo trabajado

Imaginá que una empresa evalúa una plataforma para centralizar documentos internos y gestionar tareas. El proveedor afirma que tiene altos estándares de seguridad, pero la propuesta no explica quién accede a los archivos ni cómo se recuperan después de una interrupción.

La empresa puede ordenar la conversación de esta manera:

  1. Inventariar los documentos que se cargarán y separar los que requieren mayor cuidado.
  2. Solicitar los roles disponibles y confirmar si el proveedor puede acceder al contenido para soporte.
  3. Preguntar cómo se elimina la información de los entornos principales y de las copias cuando termina el contrato.
  4. Pedir una explicación del respaldo, la recuperación y las pruebas realizadas.
  5. Identificar si el alojamiento o el soporte dependen de otros proveedores.
  6. Incorporar al acuerdo los compromisos que resulten esenciales.

Supongamos que el proveedor responde con claridad sobre roles y subcontratistas, pero no puede explicar cómo prueba la recuperación de copias. La conclusión no tiene que ser contratar o descartar de inmediato. Puede ser solicitar una alternativa, limitar inicialmente la información cargada o comparar la propuesta con otra que documente mejor ese punto.

La evaluación mejora cuando transforma una impresión general en una decisión condicionada a evidencias y compromisos concretos.

Señales de alerta en una propuesta técnica

Prestá atención cuando la propuesta usa términos amplios sin describir procesos, cuando responde una pregunta importante con una promesa comercial o cuando cambia la explicación según quién participa de la reunión. También es una alerta que el proveedor no pueda identificar un responsable para incidentes, que no explique el destino de los datos al finalizar el servicio o que presente a todos los controles como secretos imposibles de describir.

Otra señal es la falta de límites. Una propuesta seria reconoce qué cubre el servicio y qué debe hacer el cliente. Si todo aparece garantizado sin condiciones, probablemente falte precisión.

No todas las diferencias son definitivas. Un proveedor pequeño puede tener documentación menos desarrollada y aun así ofrecer respuestas honestas y un plan concreto de mejora. En ese caso, la decisión debe considerar el tipo de información, la importancia del servicio y la capacidad real de seguimiento.

Cómo evitar el alarmismo

Evaluar seguridad no significa asumir que todos los proveedores son una amenaza. Significa reconocer que una contratación crea dependencias y que esas dependencias deben administrarse.

En vez de preguntar si un proveedor es completamente seguro, preguntá qué riesgos conoce, qué controles aplica, qué límites tiene y cómo responde cuando un control falla. Esa formulación produce conversaciones más útiles y permite tomar decisiones proporcionales.

También conviene priorizar. No todos los datos ni todos los procesos tienen el mismo impacto. La revisión puede ser más profunda cuando el software concentra información sensible, sostiene una operación crítica o resulta difícil de reemplazar.

Limitaciones y supuestos

Esta guía ofrece un marco general de evaluación y no reemplaza una revisión técnica, contractual o especializada. No establece requisitos oficiales ni determina por sí sola si un proveedor debe ser aprobado.

Las preguntas deben adaptarse al tipo de software, a la información procesada, a la estructura de la empresa y a la dependencia operativa. Las respuestas pueden requerir validación adicional, especialmente cuando la propuesta incluye infraestructura de terceros o procesos que el cliente no puede observar directamente.

Se asume que la organización puede conversar con el proveedor antes de contratar y que tiene capacidad para documentar decisiones, asignar responsables y revisar cambios. Si el servicio es crítico, puede ser conveniente ampliar el análisis con profesionales adecuados.

Preguntas frecuentes

¿Tengo que hacer una auditoría completa para contratar software?

No necesariamente. Una primera evaluación puede concentrarse en accesos, datos, copias, incidentes y terceros. La profundidad dependerá del impacto del servicio y de la información involucrada.

¿Qué hago si el proveedor no comparte detalles técnicos?

Pedí información suficiente para entender responsabilidades, procesos y límites sin exigir secretos comerciales. Si no puede responder cuestiones básicas, compará el riesgo con otras alternativas antes de decidir.

¿Es mala señal que use subcontratistas?

No por sí sola. Muchos servicios dependen de terceros. Lo importante es conocer sus funciones, cómo se gestionan los cambios y quién responde cuando aparece un problema.

¿Qué debería quedar por escrito?

Como mínimo, los compromisos importantes sobre uso de datos, accesos, devolución o eliminación, copias, comunicación de incidentes y terceros relevantes.

¿Cómo comparo dos propuestas?

Usá las mismas preguntas y registrá no solo si respondieron, sino también el nivel de detalle, los responsables y qué parte quedó formalizada. La claridad también es un criterio de decisión.

Cierre y próximos pasos

La seguridad de un proveedor de software se evalúa mejor con preguntas concretas que con promesas generales. Revisá los cinco frentes, documentá las respuestas y convertí los puntos críticos en compromisos claros. Después, definí quién controlará los accesos, los cambios y la continuidad de la relación.

Para seguir explorando herramientas y criterios de decisión, consultá /guias y /catalogo. Si necesitás conversar sobre una evaluación específica, podés visitar /contacto.

Te resulto util? Compartilo con otros empresarios

¿Querés llevar esto a una implementación concreta?

Explorá servicios, precios y alcances. Armá tu presupuesto o solicitá una propuesta a medida.

¿Te resultó útil este artículo?

Si tenés alguna consulta sobre cómo aplicar estos conceptos en tu empresa, estamos para ayudarte.

Recibí las novedades

Artículos sobre IA, desarrollo de software y automatización para empresas argentinas.

Help & support