Plantilla de Evaluación de Riesgos de Proveedores

Visión General

Los proveedores de terceros procesan tus datos, se integran con tus APIs y a menudo tienen acceso privilegiado a tus sistemas. Una brecha del proveedor se convierte en tu brecha — la campaña de ransomware CL0P contra MOVEit golpeó a cientos de organizaciones a través de un único proveedor de transferencia de archivos. La mayoría de los cuestionarios de seguridad se ignoran tras la incorporación, y por eso las revisiones puntuales siguen fallando. Esta plantilla estructura una evaluación de riesgos repetible — el artefacto central de cualquier programa de gestión de riesgo de terceros (TPRM) — para evaluar proveedores antes de firmar el contrato, en las revisiones anuales y tras cualquier incidente de seguridad que les afecte.

Cuándo Usar

Usa este recurso cuando:

• Incorporas un nuevo proveedor SaaS, de nube o un equipo de desarrollo externalizado
• Realizas una revisión de seguridad anual de proveedores existentes
• Un proveedor revela una brecha o cambia su postura de seguridad

Para seguimiento de pruebas de penetración en lugar de evaluación de proveedores, consulta la Plantilla de Remediación de Pruebas de Penetración.

Solución

# Evaluación de Riesgos de Proveedor: `<Nombre del Proveedor>`

## 1. Metadatos del Proveedor

| Campo | Valor |
|-------|-------|
| Nombre del Proveedor | `nombre` |
| Servicio Proporcionado | `descripcion` |
| Nivel de Acceso a Datos | `Ninguno / Lectura / Escritura / Admin` |
| Tipos de Datos Manejados | `PII / PHI / Financieros / Confidenciales / Públicos` |
| Valor del Contrato | `$X / año` |
| Clasificación de Criticidad | `Baja / Media / Alta / Crítica` |
| Fecha de Evaluación | `AAAA-MM-DD` |
| Evaluador | `@security-team` |
| Próxima Revisión | `AAAA-MM-DD` |

## 2. Controles de Seguridad

| Categoría de Control | Declaración del Proveedor | Evidencia Solicitada | Verificado | Riesgo |
|----------------------|---------------------------|---------------------|------------|--------|
| SOC 2 Tipo II | Sí / No | Informe (últimos 12 meses) | | |
| ISO 27001 | Sí / No | Certificado | | |
| Cumplimiento GDPR / CCPA | Sí / No | DPA + política de privacidad | | |
| Cifrado en Reposos | Sí / No | Documento de arquitectura / captura | | |
| Cifrado en Tránsito (TLS 1.2+) | Sí / No | Escaneo SSL Labs | | |
| MFA para Acceso Admin | Sí / No | Captura de configuración | | |
| Prueba de Penetración (anual) | Sí / No | Resumen de informe (redactado) | | |
| Plan de Respuesta a Incidentes | Sí / No | Documento + SLAs | | |
| Sub-procesadores Publicados | Sí / No | Lista de sub-procesadores | | |

## 3. Riesgo Operativo

| Factor | Calificación | Justificación | Mitigación |
|--------|--------------|---------------|------------|
| Estabilidad financiera | `Baja / Med / Alta` | | |
| Riesgo geográfico / político | `Baja / Med / Alta` | | |
| Riesgo de concentración (proveedor único) | `Baja / Med / Alta` | | |
| Complejidad de integración | `Baja / Med / Alta` | | |
| Dificultad de salida (portabilidad de datos) | `Baja / Med / Alta` | | |

## 4. Evaluación del Manejo de Datos

| Pregunta | Respuesta del Proveedor | Satisfactorio |
|----------|------------------------|---------------|
| ¿Dónde se almacenan los datos? | `Región / país` | Sí / No |
| ¿Quién puede acceder a nuestros datos? | `Rol / proceso` | Sí / No |
| ¿Los datos se mezclan con otros clientes? | `Sí / No / Multi-tenant` | Sí / No |
| ¿Retención de datos tras fin de contrato? | `Días / política` | Sí / No |
| ¿Podemos solicitar eliminación? | `Proceso / SLA` | Sí / No |
| ¿Frecuencia y retención de copias de seguridad? | `Frecuencia / retención` | Sí / No |

## 5. Puntuación de Riesgo

| Categoría | Peso | Puntaje Bruto (1-5) | Puntaje Ponderado |
|-----------|------|---------------------|-------------------|
| Postura de seguridad | 30% | | |
| Cumplimiento | 25% | | |
| Resiliencia operativa | 20% | | |
| Protección de datos | 25% | | |
| **Total** | **100%** | | |

### Interpretación de Puntaje

| Rango | Calificación | Acción |
|-------|--------------|--------|
| 4.0 – 5.0 | Riesgo Bajo | Contrato estándar; revisión anual |
| 3.0 – 3.9 | Riesgo Medio | Requerir plan de remediación; revisión a 6 meses |
| 2.0 – 2.9 | Riesgo Alto | Mejoras de seguridad requeridas antes del onboarding |
| 1.0 – 1.9 | Riesgo Crítico | No incorporar sin aprobación del CISO + auditoría externa |

## 6. Plan de Remediación (si aplica)

| Brecha | Acción Requerida | Responsable | Fecha Límite | Estado |
|--------|-----------------|-------------|--------------|--------|
| | | | | |

Explicación

La plantilla trata la evaluación de proveedores como un proceso estructurado basado en evidencia, no un ejercicio de casillas. Cada control requiere evidencia, no solo un “sí”. La puntuación de riesgo fuerza compensaciones: un proveedor barato con cifrado deficiente puede ser aceptable para datos de marketing públicos pero nunca para registros de salud. La sección de manejo de datos es particularmente crítica porque los proveedores a menudo mezclan datos de clientes en arquitecturas multi-tenant, dificultando la eliminación y contención de brechas.

Proceso de Evaluación de Riesgo de Proveedores

1. Identificación — el equipo que solicita un nuevo proveedor rellena la solicitud de evaluación con el caso de uso y los datos a compartir; seguridad asigna un evaluador.
2. Cuestionario inicial — envía el cuestionario de seguridad (SOC 2, ISO 27001) y solicita certificaciones, políticas e informes de auditoría; revisa la página de estado y la política de notificación de brechas. Un plazo de respuesta de dos semanas funciona bien.
3. Evaluación técnica — autenticación (SSO, MFA, SAML), cifrado en tránsito y en reposo, gestión de acceso, retención y eliminación de datos, residencia y sub-procesadores.
4. Evaluación de cumplimiento — mapea los requisitos regulatorios, revisa el Acuerdo de Procesamiento de Datos, verifica las cláusulas de notificación de brechas (72 horas según GDPR) y los derechos de auditoría.
5. Decisión — calcula la puntuación ponderada, obtén la aprobación de seguridad, legal e ingeniería y documenta las condiciones.
6. Monitoreo continuo — revisión anual, notificaciones de incidentes y cambios en sub-procesadores; reevalúa cuando la postura del proveedor cambie.

Verificación del informe SOC 2

Un sello SOC 2 en la página de ventas no es evidencia. Cuando llegue el informe, verifica:

• El informe cubre el servicio concreto que vas a usar — los proveedores con varios productos suelen acotar solo el principal.
• El periodo es reciente (últimos 12 meses) y es Tipo II, no Tipo I.
• Los criterios de confianza (trust services criteria) cubren tus requisitos: Seguridad va siempre incluida; Disponibilidad, Confidencialidad, Integridad de Procesamiento y Privacidad son opcionales.
• No hay opinión con salvedades y las excepciones son menores — lee la sección de excepciones, no solo la opinión.
• La descripción del sistema coincide con la arquitectura que describió el equipo de ventas.

Automatización de la evaluación

Entre revisiones formales puedes vigilar la postura pública de un proveedor con unas pocas llamadas a APIs. Este script comprueba DNSSEC, la nota TLS, security.txt y el historial de brechas de un dominio:

import os
import requests
from dataclasses import dataclass, field

@dataclass
class VendorSecurityCheck:
    vendor_name: str
    domain: str
    results: dict = field(default_factory=dict)

    def check_dnssec(self) -> None:
        """Comprueba si el dominio del proveedor tiene DNSSEC habilitado."""
        try:
            resp = requests.get(
                f"https://dns.google/resolve?name={self.domain}&type=DNSKEY",
                timeout=10
            )
            self.results["dnssec"] = (
                "enabled" if resp.json().get("Answer") else "disabled"
            )
        except Exception:
            self.results["dnssec"] = "error"

    def check_tls(self) -> None:
        """Comprueba la configuración TLS con la API de SSL Labs."""
        try:
            resp = requests.get(
                f"https://api.ssllabs.com/api/v3/analyze?host={self.domain}"
                f"&all=done&ignoreMismatch=on",
                timeout=15
            )
            data = resp.json()
            # La API es asíncrona: devuelve status hasta que termina el análisis.
            if data.get("status") != "READY":
                self.results["tls_grade"] = f"pending ({data.get('status')})"
            else:
                grades = [e.get("grade") for e in data.get("endpoints", [])]
                self.results["tls_grade"] = min(g for g in grades if g)
        except Exception:
            self.results["tls_grade"] = "error"

    def check_security_txt(self) -> None:
        """Comprueba si hay un archivo de contacto de seguridad publicado."""
        url = f"https://{self.domain}/.well-known/security.txt"
        try:
            resp = requests.head(url, timeout=10, allow_redirects=True)
            self.results["security_txt"] = url if resp.status_code == 200 else "not found"
        except Exception:
            self.results["security_txt"] = "not found"

    def check_breach_history(self) -> None:
        """Consulta el historial de brechas del dominio en Have I Been Pwned.

        Requiere una API key de pago en la variable de entorno HIBP_API_KEY;
        el endpoint /breacheddomain devuelve las brechas del dominio.
        """
        key = os.environ.get("HIBP_API_KEY")
        if not key:
            self.results["breaches"] = "skipped (no HIBP_API_KEY)"
            return
        try:
            resp = requests.get(
                f"https://haveibeenpwned.com/api/v3/breacheddomain/{self.domain}",
                headers={"hibp-api-key": key, "User-Agent": "VendorAssessment/1.0"},
                timeout=10
            )
            if resp.status_code == 200:
                self.results["breach_count"] = len(resp.json())
            elif resp.status_code == 404:
                self.results["breach_count"] = 0
            else:
                self.results["breaches"] = f"error {resp.status_code}"
        except Exception:
            self.results["breach_count"] = "error"

    def run_all(self) -> dict:
        self.check_dnssec()
        self.check_tls()
        self.check_security_txt()
        self.check_breach_history()
        return self.results

# Ejemplo de uso
vendor = VendorSecurityCheck(vendor_name="Acme Cloud", domain="acmecloud.com")
for key, value in vendor.run_all().items():
    print(f"  {key}: {value}")

Y este puntúa el cuestionario cuando lleguen las respuestas:

from dataclasses import dataclass, field

@dataclass
class VendorRiskScorer:
    scores: dict  # categoría -> puntuación (1-5)
    weights: dict = field(default_factory=lambda: {
        "security": 0.30,
        "compliance": 0.25,
        "operational": 0.20,
        "data_protection": 0.25,
    })

    @property
    def total_score(self) -> float:
        return round(sum(
            self.scores.get(cat, 0) * weight
            for cat, weight in self.weights.items()
        ), 2)

    @property
    def decision(self) -> str:
        score = self.total_score
        if score >= 4.0:
            return "RIESGO BAJO — contrato estándar, revisión anual"
        if score >= 3.0:
            return "RIESGO MEDIO — plan de remediación, revisión a 6 meses"
        if score >= 2.0:
            return "RIESGO ALTO — mejoras requeridas antes de incorporar"
        return "RIESGO CRÍTICO — no incorporar sin aprobación del CISO"

    @property
    def critical_gaps(self) -> list:
        return [
            f"{cat}: {score}/5 es crítico"
            for cat, score in self.scores.items() if score <= 2
        ]

# Ejemplo de uso
scorer = VendorRiskScorer(scores={
    "security": 4, "compliance": 5, "operational": 3, "data_protection": 4,
})
print(scorer.total_score)   # 4.05
print(scorer.decision)      # RIESGO BAJO — contrato estándar, revisión anual

Ejecuta ambos desde CI semanalmente y guarda los resultados junto a la evaluación — un proveedor cuya nota TLS baja de A a C entre revisiones es una señal que merece reevaluación.

Clasificación de proveedores antes de evaluar

Aplicar la plantilla completa a todos los proveedores desperdicia ciclos de revisión — un SaaS de tres personas que renderiza tu logo no merece el mismo escrutinio que el procesador que aloja tu base de datos. Clasifica por nivel de acceso a datos, no por el tamaño del contrato:

Nivel	Perfil	Profundidad de evaluación
Crítico	Maneja PII/PHI, acceso privilegiado o difícil de reemplazar	Plantilla completa + verificación SOC 2 + revisión anual
Estándar	Datos de negocio, reemplazable, integraciones estándar	Plantilla completa, sin visita in situ; revisión en cada renovación
Bajo	Solo datos públicos, sin integraciones	Cuestionario corto (10 preguntas) + comprobaciones de postura de la sección de automatización

La clasificación también responde a “qué profundidad debe tener el cuestionario” — el SIG Lite (~150 preguntas) encaja con el nivel Estándar, mientras que los proveedores Críticos justifican el SIG completo. Si tu organización ya clasifica datos, reutiliza las etiquetas de la plantilla de clasificación de datos para que los niveles sean consistentes.

Variantes

Contexto	Enfoque	Verificaciones Adicionales
Infraestructura en la nube (IaaS)	Modelo de responsabilidad compartida	Verificar dónde termina la responsabilidad del proveedor y comienza la tuya
SaaS con integración API	Seguridad de OAuth / tokens	Revisar alcances, rotación de tokens y firma de webhooks
Desarrollo externalizado	Acceso al código fuente	NDA, verificaciones de antecedentes, prácticas de desarrollo seguro
Procesador de pagos	PCI DSS	Requerir AoC (Attestation of Compliance) y SAQ
Proveedor de IA / ML	Datos de entrenamiento del modelo	Verificar que tus datos no se usen para entrenar modelos a menos que se acuerde explícitamente

Lo que funciona

1. Evalúa proveedores antes de la firma del contrato, no después del onboarding
2. Requiere un Acuerdo de Procesamiento de Datos (DPA) para cualquier proveedor que toque PII
3. Revisa sub-procesadores anualmente; el proveedor de tu proveedor sigue siendo tu riesgo
4. Mantén una lista de verificación de offboarding que incluya verificación de eliminación de datos
5. Documenta la justificación para cualquier riesgo aceptado; los auditores lo pedirán

Errores Comunes

1. Aceptar el cuestionario de seguridad de un proveedor sin solicitar evidencia
2. Tratar a todos los proveedores igual independientemente de la sensibilidad de los datos o nivel de acceso
3. No reevaluar proveedores después de una violación o adquisición
4. Ignorar sub-procesadores; muchas violaciones ocurren a nivel de cuarta parte
5. No tener un plan de salida; los proveedores saben que los costos de migración te mantienen atado

Solución de problemas

• El proveedor frena el cuestionario: envía primero la versión corta (10 preguntas sobre cifrado, control de acceso e incidentes) y escala la completa solo si la supera. Los proveedores que no responden la versión corta rara vez pasan la evaluación.
• Los evaluadores no se ponen de acuerdo en las puntuaciones: puntúa de forma independiente y discute solo las categorías con 2+ puntos de divergencia. Promedia el resto y sigue adelante.
• La evidencia está obsoleta: trata cualquier documento de más de 12 meses como ausente. Un SOC 2 de hace dos años solo te dice que fueron conformes una vez — nada sobre hoy.
• Un proveedor heredado es anterior al proceso: haz una evaluación retroactiva ordenada por nivel de acceso a datos; no intentes exonerar a nadie.

Lecturas recomendadas

• NIST Cybersecurity Framework 2.0 — Gestión de riesgo de la cadena de suministro — las categorías de riesgo de proveedores a las que mapea este proceso.
• AICPA SOC 2 — Trust Services Criteria — qué cubre realmente un informe Tipo II.
• Cuestionario SIG de Shared Assessments — el cuestionario estándar del sector que esta plantilla complementa para proveedores grandes.
• ICO — Contratos entre responsables y encargados del tratamiento (GDPR Art. 28) — qué debe contener un DPA.
• ISO/IEC 27001:2022 — el estándar de SGSI referenciado en la sección de cumplimiento.