Guía para seleccionar proveedores de servicios TI según criterios de riesgo, cumplimiento y seguridad

Quien debe seleccionar un proveedor de servicios de TI decide no solo sobre tarifas diarias y disponibilidad, sino sobre una ampliación de su propia superficie de ataque, sobre obligaciones de demostración regulatorias y sobre la pregunta de qué tan rápido puede volver a estar operativo en caso de incidente. En muchas empresas los proveedores pasan de facto a ser coadministradores: administran sistemas, mueven datos, configuran mecanismos de seguridad e influyen en procesos operativos. Precisamente por eso una “buena impresión en la presentación” no basta.

Este artículo está pensado como ayuda para la toma de decisiones para la dirección de TI, seguridad de la información (ISMS), protección de datos, cumplimiento y dirección ejecutiva. Muestra un enfoque práctico para evaluar proveedores basado en riesgos: qué evidencias son razonables, qué controles son imprescindibles, cómo establecer governance y responsabilidades, y cómo evitar trampas típicas (subcontratistas, acceso a registros, exit, cadenas de evidencia). El objetivo es una decisión de selección que resista una auditoría y que no genere sorpresas en operación.

1) Punto de partida: ¿Qué significa concretamente “riesgo” en proveedores de TI?

En el contexto de proveedores, el riesgo no es abstracto sino muy concreto: se trata de la combinación de probabilidad de ocurrencia y impacto sobre confidencialidad, integridad y disponibilidad (tríada CIA). Además cuenta la capacidad de evidencia: ¿puede demostrar que los controles existen y funcionan?

Para la evaluación ayuda una separación clara en cuatro dominios de riesgo:

• Riesgo de datos: ¿Qué datos procesa el proveedor (personales, confidenciales, secretos comerciales)? ¿Dónde se almacenan, cómo se cifran, quién tiene acceso?
• Riesgo de accesos y operativos: ¿Recibe el proveedor acceso de administrador, acceso shell, acceso VPN o solo acceso basado en tickets? ¿Existen accesos de emergencia? ¿Se realizan los cambios según la gestión de cambios?
• Riesgo de la cadena de suministro: subcontratistas (p. ej. proveedores de nube, cadenas de soporte), cambios de ubicación, dependencias, herramientas propietarias, obstáculos de salida.
• Riesgo de cumplimiento y auditoría: RGPD, normas sectoriales, políticas internas, retención, registro, obligaciones de evidencia, derechos de auditoría.

Una decisión de selección sólida exige que primero describa con precisión el uso previsto del proveedor: sistemas, clases de datos, privilegios, ventanas operativas, RTO/RPO (objetivo de tiempo de recuperación / objetivo de punto de recuperación) y las interfaces organizativas. Sin esta delimitación, cualquier assessment será o demasiado blando (“todo es importante”) o demasiado rígido (“todo está prohibido”).

2) Clasificación de riesgos antes del screening: Tiering en lugar del instinto

En la práctica funciona una Tiering (clasificación en niveles de criticidad) que controla el esfuerzo de diligencia debida y las cláusulas contractuales. Así evita desplegar la maquinaria completa de auditoría por cada pequeño contrato de soporte, y al mismo tiempo se asegura de que los socios críticos no pasen desapercibidos.

Propuesta para 4 niveles (ajustable)

• Tier 1 – Crítico: accesos Admin/Root, redes de entorno productivo, procesamiento de datos sensibles, operación de procesos críticos, impactos significativos por interrupción.
• Tier 2 – Alto: acceso a sistemas importantes o grandes volúmenes de datos, pero con RESTricciones (p. ej. solo a través de Jump-Host, alcance estrictamente separado).
• Tier 3 – Medio: acceso limitado, mayoritariamente consultoría/trabajo de proyecto, procesamiento de datos RESTringido.
• Tier 4 – Bajo: sin o con procesamiento de datos mínimo, sin acceso a sistemas productivos (p. ej. formación).

Un Tiering no debería depender únicamente de «Cloud vs. On-Prem», sino de Privilegios, clases de datos y responsabilidad operativa. Un administrador externo en la red interna suele ser con frecuencia más arriesgado que un servicio SaaS con un modelo de tenant limpio y evidencias claras.

3) Pregunta clave en el proceso de selección: ¿Qué modelo operativo asume usted mismo – y qué delega realmente?

Muchos conflictos posteriores surgen por expectativas imprecisas: «Managed» no significa automáticamente 24/7, ni automáticamente aplicar parches, ni automáticamente realizar pruebas de backup/RESTore. Por eso el modelo operativo debe describirse en lenguaje operativo antes de la firma del contrato.

Delimitación práctica: RACI y artefactos operativos

RACI asigna roles: Responsible (ejecutor), Accountable (responsable último), Consulted (consultado), Informed (a informar). Para las auditorías es especialmente importante que «Accountable» permanezca claramente definido, incluso si un proveedor actúa operativamente.

Artefactos que debe solicitar de forma vinculante a los proveedores críticos:

• Manual de operaciones/Runbooks (rutina y emergencia)
• Proceso de cambios incl. reglas de aprobación y rollback
• Vías de monitorización y alertas (incl. turnos de guardia)
• Concepto de copias de seguridad y RESTauración (incl. evidencias de pruebas)
• Gestión de parches y vulnerabilidades (ciclos, excepciones, autorizaciones de riesgo)
• Gestión de incidentes incl. evidencia (aseguramiento de pruebas) y matriz de comunicaciones

4) Cumplimiento y evidencias: ¿Qué documentos ayudan realmente?

El cumplimiento a menudo se confunde con «papel». Lo decisivo es si las evidencias son verificables y adecuadas al alcance. Un certificado ISO 27001 puede ser valioso, pero sin comprobar el alcance dice poco. Un informe SOC 2 (Tipo II) puede ser muy útil, pero solo si los controles se corresponden con su riesgo y las excepciones (Exceptions) se entienden y abordan.

Evidencias que en la práctica aportan sustancia

• Evidencias ISMS: ISO 27001 (alcance, Statement of Applicability), políticas internas, tratamiento de riesgos.
• SOC 2 Tipo II: periodo, criterios de Trust Services auditados, hallazgos/excepciones, organizaciones de subservicio.
• Evidencias de pruebas de penetración/gestión de vulnerabilidades: frecuencia, alcance, manejo de hallazgos (sin que tenga necesariamente que recibir los informes detallados).
• Documentación de protección de datos: AVV (contrato de encargado del tratamiento), TOMs (medidas técnicas y organizativas), lista de subprocesadores, concepto de eliminación y devolución.

Importante: «Cumplimos con la DSGVO» no es una afirmación suficiente. Para la DSGVO necesita bloques concretos: AVV, finalidad, categorías de afectados, tipos de datos, plazos de borrado, medidas técnicas, transferencias internacionales (p. ej. cláusulas contractuales estándar) y una gestión sólida de subcontratistas.

5) Criterios de seguridad para la selección: controles que importan en el funcionamiento

Para la decisión de selección debe formular los criterios de seguridad de forma que sean posteriormente operativos. En lugar de «alta seguridad» necesita requisitos verificables. A continuación las familias de controles que en las relaciones con proveedores suelen resultar decisivas.

Identidades y accesos privilegiados (IAM/PAM)

IAM (Gestión de Identidad y Acceso) regula identidades, roles y permisos. PAM (Gestión de Accesos Privilegiados) controla accesos administrativos especialmente potentes, idealmente con limitación temporal y trazabilidad.

• Usuarios individuales en lugar de cuentas compartidas
• MFA (autenticación multifactor) obligatoria
• Just-in-Time/Just-Enough-Access, cuando sea posible
• Acceso a través de Jump-Hosts/Bastion, sin inicios de sesión administrativos directos desde Internet
• Grabación de sesiones o, al menos, registros de auditoría detallados para acciones privilegiadas

Pregunta de comprobación: ¿Puede demostrar en caso de incidente quién cuándo qué hizo, y puede revocar accesos en cuestión de minutos?

Red y separación de inquilinos

Especialmente en Managed Services la segmentación es decisiva: redes separadas para gestión, producción, backup, logging; reglas de firewall claras; y un reglamento documentado para excepciones. La separación de inquilinos es clave en proveedores SaaS: aislamiento lógico (tenant isolation), cifrado y protección contra la fuga de datos por mala configuración.

Gestión de vulnerabilidades y parches

Para la selección y el contrato cuenta menos el «turno de parches» que la capacidad para gestionar riesgos: ¿cómo se prioriza (crítico/alto/medio), cómo se documentan las excepciones, cómo se compensan (p. ej. reglas WAF, aislamiento), y con qué rapidez se pueden aplicar hotfixes?

Una evidencia sencilla pero eficaz es una exportación periódica del proceso de tickets/vulnerabilidades (anonimizada) que muestre: entrada, valoración, plazo, implementación, revisión.

Logging, monitorización y capacidad forense

Aquí se decide la capacidad de auditoría: sin registros fiables (marcas temporales, protección de integridad, conservación) los incidentes quedan en el terreno de la opinión. Es especialmente delicado cuando los logs residen en el proveedor pero usted, como cliente, tiene la obligación de demostrar los hechos.

• Fuentes de logs definidas (autenticación, acciones de administrador, cambios de sistema, accesos a API)
• Almacenamiento central con un concepto de acceso (principio de menor privilegio)
• Plazos de retención acordes con la regulación y las políticas internas
• Integridad (protección contra manipulación) y sincronización temporal (NTP)

6) Protección de datos y soberanía de los datos: AVV es solo el comienzo

La protección de datos suele reducirse al AVV al elegir proveedores. Eso es arriesgado, porque las cuestiones críticas están en la implementación técnica: ¿dónde se procesan los datos, cómo se cifran, cómo se realiza la eliminación y cómo se ejecuta la devolución de datos en el exit?

Requisitos concretos que debe documentar

• Localización de datos: regiones/centros de datos, transferencias internacionales, bases legales.
• Cifrado: en tránsito (TLS) y en reposo; gestión de claves (KMS), acceso a las claves.
• Copias de seguridad: ¿contienen datos personales? ¿Cómo se eliminan las copias de seguridad? ¿Qué periodo de retención aplica?
• Solicitudes de los interesados: apoyo en acceso/eliminación/exportación, plazos y proceso.
• Modelo de roles: ¿quién es el responsable, quién el encargado del tratamiento, quién el subencargado?

Si tiene requisitos estrictos (p. ej. claves bajo su control, „Bring Your Own Key“), esos requisitos deben incluirse antes de la selección como criterios obligatorios. Posteriormente, esos puntos suelen ser costosos o técnicamente inviables.

7) Subcontratistas y cadena de suministro: el punto ciego en la gestión de proveedores

Muchos riesgos no surgen con el socio seleccionado, sino en la cadena: alojamiento en la nube, 24/7-NOC, equipos de desarrollo externos, soporte en otras jurisdicciones. Los subcontratistas no son per se negativos – pero deben ser transparentes, controlables y estar cubiertos contractualmente.

En qué debe insistir

• Lista actual de subcontratistas con participaciones en el servicio y accesos a los datos
• Proceso de cambios: información previa y derechos de objeción/rescisión ante cambios críticos
• Cláusulas de „flow-down“: los requisitos de seguridad y protección de datos se aplican en la cadena
• Derecho a inspeccionar las evidencias relevantes (p. ej. SOC-Reports de la organización subcontratada de servicios)

8) Lógica contractual y de SLA: los requisitos de seguridad deben volverse medibles

Los contratos rara vez fracasan por un párrafo ausente, sino por expectativas no medibles. Los SLA (Service Level Agreements) describen objetivos de servicio (p. ej. disponibilidad, tiempos de respuesta). Los OLA (Operational Level Agreements) son acuerdos internos/operativos entre equipos o entre unidades del proveedor que hacen posible el cumplimiento de los SLA.

Elementos típicos de SLA que debe concretar

• Clasificación de incidentes: definiciones P1/P2/P3 basadas en el impacto en el negocio
• Tiempos de respuesta y recuperación: no solo „Response“, sino „RESTore“
• Ventanas de cambio: estándar vs. Emergency Changes, obligación de documentación
• Security SLAs: plazos para la resolución de vulnerabilidades críticas, ciclos de parches, reglas de excepción
• Reporting: informes de servicio mensuales con métricas definidas y análisis de desviaciones

Importante desde la perspectiva de auditoría: si contractualiza controles de seguridad, también necesita una rutina de medición y verificación. De lo contrario se genera una brecha entre el contrato y la realidad.

9) Perspectiva de auditoría: qué suelen requerir los revisores

Las auditorías rara vez examinan detalles técnicos aislados; se centran en la gobernabilidad: ¿existe un procedimiento, se documentan las decisiones, están claras las responsabilidades y son efectivos los controles? En las relaciones con proveedores muchas revisiones se reducen a tres preguntas:

• ¿Se evaluaron los riesgos antes de la contratación? (diligencia debida, tiering, autorizaciones)
• ¿Están los controles en operación y reflejados en el contrato? (SLA, requisitos de seguridad, protección de datos, subcontratistas)
• ¿Puede demostrar la eficacia? (informes, registros, pruebas, actas de revisión)

Ser apto para auditoría no implica sobrecarga documental. Significa: decisiones trazables, documentación concisa, evidencia almacenada de forma central y realización de revisiones periódicas.

10) Lista de verificación práctica: preguntas de due diligence que realmente ayudan en la selección

La lista siguiente está pensada como un núcleo pragmático. No sustituye a un análisis de riesgos individual, pero cubre los criterios de decisión típicos que después serán relevantes en el funcionamiento y en la auditoría.

A) Alcance y acceso

• ¿Qué sistemas/entornos están en el alcance (Prod/Stage/Dev)?
• ¿Qué tipos de acceso son necesarios (VPN, jump-host, API, solo por ticket)?
• ¿Cómo se conceden, registran y revocan los accesos privilegiados?

B) Controles de seguridad

• ¿Qué estándares mínimos aplican (MFA, política de contraseñas, hardening, EDR/AV)?
• ¿Cómo se gestiona el parcheo y la gestión de vulnerabilidades, incl. priorización y excepciones?
• ¿Cómo se implementa el logging, quién tiene acceso y qué política de retención se aplica?

C) Protección de datos y gestión de datos

• AVV/TOMs: ¿están actualizados y se ajustan al proceso real?
• Ubicación de datos, subcontratistas, transferencias internacionales: ¿están descritos con claridad?
• Eliminación, devolución y retención de backups: ¿es operativamente viable?

D) Operación, resiliencia, emergencia

• Monitorización y on-call: ¿horarios, vías de escalado, canales de comunicación?
• Backup/RESTore: ¿se prueban y documentan las RESTauraciones?
• BCM/DR: ¿hay pruebas y cuáles fueron los últimos resultados?

E) Gobernanza y evidencias

• ¿Qué pruebas (ISO/SOC) existen y qué alcance cubren?
• ¿Cómo se documentan los cambios, incidentes y revisiones?
• ¿Existe un derecho de auditoría y cómo se aplica en la práctica (p. ej. auditoría remota, acceso a informes)?

11) Enfoque de scorecard: hacer la decisión transparente (sin falsa precisión)

Una scorecard ayuda a comparar varios proveedores y a justificar la decisión ante la dirección, la auditoría o protección de datos. Importante: no crear una falsa sensación de precisión. Use pocos criterios, ponderación clara y documente las desviaciones con medidas compensatorias.

Propuesta de ponderación (ejemplo)

• 30% Seguridad & controles de acceso
• 25% Operaciones & resiliencia (RTO/RPO, runbooks, on-call)
• 20% Cumplimiento & evidencias (ISO/SOC/AVV, auditabilidad)
• 15% Cadena de suministro & control de subcontratistas
• 10% Factores comerciales (modelo de costes, transparencia, flexibilidad)

Para proveedores de nivel 1 deberían existir criterios obligatorios que no se puedan „ponderar“ (p. ej. MFA, cuentas individuales, AVV para datos personales, cláusula de salida, logging). Si no se cumple un criterio obligatorio, el proveedor queda fuera o se requiere una autorización formal de riesgo con compensación.

12) Planificación de salida y de emergencia: criterio de selección, no un pensamiento final

Salir suena a fin de contrato, pero es una palanca de seguridad y operación: ¿qué ocurre en caso de insolvencia, incidente grave, disputa, parada regulatoria o cambio estratégico? Sin un plan de salida aumenta el riesgo de vendor lock-in y, en una emergencia, falta tiempo para entregar datos y know‑how de forma ordenada.

Elementos que deben incluirse en la selección y el contrato

• Devolución de datos: formatos, completitud, plazos, responsabilidades
• Confirmación de eliminación: incluidas copias de seguridad/copias de archivo (en la medida técnica posible, descrito con transparencia)
• Entrega de documentación: Runbooks, arquitectura, configuraciones, inventario de claves/certificados
• Soporte de transición: horas/contingentes definidos, tareas priorizadas, acceso para el sucesor
• Salida de emergencia: rescisión especial, acceso a sistemas/logs, congelación de cambios

Desde la perspectiva operativa es especialmente importante que no solo reciba „datos“ de vuelta, sino también la capacidad operativa: configuraciones, modelos de acceso, setups de monitorización y procedimientos de recuperación.

13) Bloques de origen prácticos: plantillas para políticas y comandos de verificación

Los siguientes ejemplos se han mantenido deliberadamente genéricos y deben adaptarse a su entorno. Puede utilizarlos como punto de partida para políticas internas, requisitos a proveedores o comprobaciones de auditoría.

Plantilla de política: requisitos mínimos para accesos de proveedores

POLÍTICA: Acceso de terceros a sistemas TI (requisitos mínimos)

1. Identidades
- Solo cuentas de usuario individuales, no cuentas compartidas.
- MFA obligatorio para todos los accesos externos.
- Permisos basados en roles (Least Privilege), privilegios de administrador con duración limitada (Just-in-Time).

2. Vías de acceso
- Accesos administrativos únicamente a través de Jump-Hosts/Bastion definidos o una solución PAM.
- No hay acceso administrativo directo desde Internet.
- Acceso solo desde redes/fuentes aprobadas (Allowlist), en la medida de lo posible.

3. Registro
- Autenticación, acciones privilegiadas y cambios de configuración se registran de forma centralizada.
- Los registros están protegidos contra manipulación y se conservan según los requisitos de retención.

4. Incorporación/Desvinculación
- Proceso de aprobación antes de la puesta en marcha, incl. ticket y responsable.
- Desaprovisionamiento dentro de un plazo definido tras el cambio de rol/fin del proyecto.

5. Excepciones
- Excepciones solo con evaluación de riesgo documentada, fecha de caducidad y medidas de compensación.

Comandos de verificación (ejemplos): trazabilidad de accesos administrativos bajo Linux

En muchos entornos es importante saber si las acciones privilegiadas son rastreables. Los siguientes checks ayudan a verificar fundamentos típicos (Auditd/Journal/Sudo). No constituyen una auditoría de seguridad completa, pero sí una comprobación rápida de la realidad durante la incorporación o una revisión.

# Prüfen, ob sudo-Aktionen geloggt werden (Beispielpfade je nach Distribution)
sudo grep -R "^Defaults" /etc/sudoers /etc/sudoers.d 2>/dev/null | head

# Letzte sudo-Ereignisse (wenn über journald erfasst)
sudo journalctl -u sudo --since "7 days ago" 2>/dev/null | tail -n 50

# Prüfen, ob auditd aktiv ist
sudo systemctl status auditd --no-pager

# Audit-Regeln anzeigen (falls auditd genutzt wird)
sudo auditctl -l 2>/dev/null | head -n 50

Para la evaluación de un proveedor importa menos que se utilice una herramienta concreta y más si se alcanza su objetivo: huellas de auditoría inmutables, centralizadas y analizables para las acciones relevantes.

14) Valorar de forma realista costes y esfuerzo: la seguridad no es gratis, la inseguridad sale más cara

Una selección basada en riesgos ahorra dinero si evita que compre «barato» en el lugar equivocado. Bloques de costes típicos que se subestiman en los casos de negocio:

• Costes de transacción: onboarding, due diligence, revisión de contratos, integración de herramientas
• Costes de control: revisiones, informes, auditorías, pruebas de penetración, recertificación de accesos
• Costes por incidentes: análisis forense, tiempo de inactividad, comunicación con clientes, notificaciones regulatorias
• Costes de lock-in: proyecto de salida, migración de datos, transferencia de conocimiento

Un enfoque pragmático: trate a los proveedores Tier-1 como si fuesen sistemas internos críticos. Eso no significa «hacerlo todo usted mismo», sino asegurar control: roles claros, puntos de medición claros, evidencia clara.

15) Gobernanza en el día a día: ¿quién decide qué y quién asume qué responsabilidades?

La gobernanza de proveedores solo funciona si se aplica en el día a día. Esto incluye rituales establecidos y responsabilidades claras:

• Service Owner en el lado del cliente: responsable técnico/operativo, evalúa informes y gestiona el backlog
• Security/Compliance: define controles obligatorios, revisa desviaciones, aprueba excepciones
• Protección de datos: evalúa flujos de datos, AVV/TOMs, transferencias, conceptos de eliminación
• Provider Manager (o compras/legal): gestión contractual y de escalaciones
• Operaciones de TI: integra monitorización, logging, backups, cambios, procesos on-call

Han demostrado su eficacia las Service Reviews trimestrales (SLA, incidentes, cambios, hallazgos de seguridad) y una reevaluación anual para Tier-1/2. No como formalidad, sino como momento para preguntas duras: ¿han cambiado el alcance, los subcontratistas, las clases de datos o los patrones de acceso?

Conclusión: seleccionar proveedores de TI significa comprar riesgos gestionables

Una buena decisión de selección se basa en un principio simple: cuanto mayor sea el acceso y más crítica la responsabilidad sobre datos u operaciones, más rigurosas deben ser las pruebas, los controles y las reglas de salida.

Si combina de forma coherente el Tiering, la scorecard y los criterios imprescindibles, evitará dos extremos: requisitos desproporcionados para proveedores no críticos y vacíos peligrosos con socios críticos.

Apoye criterios verificables (IAM/PAM, logging, procesos de parcheo, control de subcontratistas), anclélos contractualmente de forma medible (SLA/Security SLAs) y planifique desde el principio las salidas y las transferencias de emergencia. Así, la gestión de proveedores será menos «corazonada» y más una disciplina auditable y operativa.

Para este tema también son importantes la gestión de riesgos de terceros y la gestión de proveedores de TI. El artículo contextualiza estos aspectos de forma comprensible y muestra qué resulta relevante en la práctica cotidiana.