Evaluación de proveedores de software. Seguridad y propiedad

Respuesta breve

No compre una promesa de seguridad. Compre responsabilidades verificables. Antes de firmar, cada cuenta importante, flujo de datos, integración, decisión operativa y actividad de entrega debe tener una persona responsable. Solicite un mapa de datos actual, un modelo de acceso, un procedimiento de incidentes, evidencia de recuperación, un catálogo de API y un plan de entrega. Esta guía no es asesoramiento jurídico ni afirma que un control concreto produzca cumplimiento legal.

Mapa de datos y preguntas sobre roles

Prepare una fila para cada flujo con origen, finalidad, tipo de datos, destinatario, ubicación de almacenamiento, roles de acceso, conservación y ruta de exportación o borrado. Diferencie datos de clientes, registros, analítica, copias de seguridad y datos de prueba. Pregunte quién aprueba un cambio de finalidad y quién responde a una solicitud de la persona interesada.

El RGPD diferencia entre responsable y encargado. El artículo 28 indica que un contrato para tratamiento por cuenta del responsable debe cubrir, entre otros elementos, objeto, duración, naturaleza, finalidad, tipos de datos, categorías de interesados, obligaciones y derechos. Valide las funciones concretas con asesoría jurídica y con la persona responsable de privacidad. Pregunte quién determina la finalidad y los medios, qué subencargados intervienen y cómo se notifican sus cambios. La información de privacidad de Rise.sk no sustituye el análisis contractual de su proyecto.

Acceso, auditoría y desarrollo seguro

Pida un registro de entornos y cuentas. Debe incluir administradores de nube, bases de datos de producción, repositorios, CI, dominios, correo, analítica, cuentas publicitarias y herramientas de soporte. Compruebe que cada persona tenga una cuenta propia, que las funciones sensibles usen autenticación multifactor y que exista un proceso documentado para retirar acceso cuando alguien cambia de función o se marcha.

La pista de auditoría debe permitir responder quién realizó una acción sensible, cuándo, desde qué cuenta y con qué resultado. Solicite evidencia de inicios de sesión administrativos, cambios de permisos, exportaciones, cambios de configuración e intervenciones en producción. OWASP ASVS puede servir como base de compra para comprobar controles técnicos de aplicaciones. No es un sello de producto. Los principios públicos están en la página de seguridad de Rise.sk.

Pregunte cómo protege el proveedor el código fuente, revisa cambios y trata dependencias vulnerables. Pida el proceso de revisión de código, búsqueda de secretos, actualización de bibliotecas, valoración de gravedad y corrección urgente fuera de la entrega habitual. NIST SP 800-218 describe prácticas para integrar desarrollo seguro durante el ciclo de vida. CISA Secure by Design sostiene que la carga de seguridad no debe recaer solo en el cliente.

Copias, incidentes y API

Una copia de seguridad necesita más que una respuesta afirmativa. Pregunte dónde se guarda, cómo se protege, cuánto se conserva, quién puede restaurarla y cuándo se probó la restauración. Acuerde objetivos de recuperación de datos y servicio, contacto para incidentes, primera actualización de estado y preservación de evidencias. ENISA Threat Landscape 2024 aporta contexto para conversar sobre amenazas y resiliencia. Un plan escrito no prueba una recuperación ensayada.

Cada API crea una obligación operativa y de propiedad. Registre responsable, finalidad, base contractual, autenticación, límites, versión, costes, datos personales y procedimiento de error. Debe conocer el efecto de un token caducado, respuesta lenta, mensaje duplicado, cambio incompatible o caída de un tercero. Prepare una continuidad manual para cada proceso crítico. Compare la entrega, la decisión y la aceptación con el proceso de Rise.sk.

Propiedad, licencias, soporte y salida

El contrato y sus anexos deben identificar por separado código fuente, repositorios, dominios, cuentas cloud, bases de datos, DNS, correo, analítica, cuentas publicitarias, archivos de diseño, documentación, contraseñas y códigos de recuperación. Para cada activo anote derecho, administrador, contacto de facturación, ubicación y acción de entrega. Un activo del cliente no debe depender del correo personal de un empleado del proveedor.

Revise licencias de código propio, paquetes de código abierto, plantillas, fuentes, fotografías, API y servicios de pago. Pregunte por límites, renovaciones, plazo mínimo, exportación y consecuencias del impago. Un SLA debe diferenciar horario de soporte, prioridad, objetivo de respuesta, objetivo de recuperación, ventana de mantenimiento y exclusiones. Un objetivo sin alcance ni medición no es una garantía.

Valide el plan de salida antes de iniciar el proyecto. Debe incluir exportación de datos con formato descrito, historial del repositorio, inventario de cuentas e integraciones, documentación de infraestructura, instrucciones de despliegue, transferencia segura de secretos y asistencia de transición. Pruebe una exportación pequeña y el acceso del cliente a una cuenta propia. El paquete de evidencia puede incluir mapa de datos, registro de acceso, última prueba de recuperación, inventario de dependencias, hallazgos de seguridad, lista de subencargados, catálogo de API, SLA y criterios de aceptación.

El anexo contractual debe cubrir alcance del sistema, propiedad, roles de datos, medidas de seguridad, notificación de incidentes, copias, integraciones, licencias, soporte, exportación y entrega. La redacción jurídica debe revisarse para cada caso. Negocio, TI, finanzas, marketing y privacidad necesitan una decisión, responsable y fecha para cada punto abierto. Los servicios de Rise.sk pueden apoyar una evaluación técnica. Hay más material en el blog. Lea las condiciones antes de contratarnos.

Fuentes

• RGPD en EUR-Lex
• OWASP ASVS
• NIST SP 800-218 SSDF
• CISA Secure by Design
• ENISA Threat Landscape 2024