Dónde se atasca el 90% de los programas de terceros
El proceso estándar tiene seis pasos y los cinco primeros son fáciles de escribir: convocar a las áreas, definir requisitos, clasificar proveedores por criticidad, estandarizar el proceso, armar el cuestionario. El sexto —"define criterios objetivos de evaluación"— es donde el documento se vuelve vago y donde el programa real se detiene.
La consecuencia es concreta: dos analistas puntúan distinto el mismo hallazgo, la decisión queda sin fundamento escrito, y en auditoría no se puede explicar por qué este proveedor entró y aquel no. El expediente existe, pero no sostiene nada.
La pregunta que hay que poder responder por escrito: ¿qué evidencia, con qué nivel de respaldo, hace que esta dimensión se considere cubierta para este proveedor bajo este marco? Si la respuesta vive en la cabeza del analista, el programa no es auditable.
Lo que el proveedor ya publicó no se pregunta
Antes de la tabla, una corrección de método. Buena parte de lo que un cuestionario de seguridad pregunta ya está publicado por el propio proveedor: sus certificaciones, su lista de subencargados, dónde procesa, si ofrece DPA, a quién se le reporta una vulnerabilidad. Suele vivir en las mismas rutas: /security, /trust, /privacy, /dpa, /subprocessors.
Mandar un cuestionario de 200 preguntas para averiguar eso genera semanas de espera y una respuesta que igual habrá que verificar. El cuestionario debería quedar para lo que sólo el proveedor sabe. Y hay un corolario que casi nadie registra:
Que un proveedor no publique su lista de subencargados es, en sí, un hallazgo. No es un hueco de tu revisión. Un expediente que sólo enumera lo que encontró —y calla lo que buscó y no estaba— se lee como completo cuando no lo es.
La tabla: qué revisar y qué significa aprobar
Once dimensiones, la evidencia que corresponde pedir en cada una, y —la columna que falta en todos lados— qué se considera cubierto.
| Dimensión | Evidencia a revisar | Qué significa que cumpla |
|---|---|---|
| Certificaciones | ISO 27001, SOC 2 Tipo I o II, ISO 27701, PCI DSS. Alcance y fecha. | El alcance del certificado cubre el servicio que vas a contratar, y está vigente. "Alineado con" no es "certificado". |
| Protección del dato | Cifrado en tránsito y en reposo, retención, borrado y plazo tras terminar el contrato. | Declara algoritmo y plazos concretos. "Cifrado de nivel bancario" sin algoritmo ni plazo es el hallazgo. |
| Gestión de accesos | SSO, SAML, SCIM, MFA obligatorio, registros de auditoría exportables. | Puedes gobernar los accesos desde tu lado: altas, bajas y revisión periódica sin depender de un ticket. |
| Subencargados | Lista publicada: quiénes son, para qué y dónde procesan. | La lista existe, está completa y su contrato lo obliga a exigirles lo mismo (ver flow-down). |
| Dónde procesa | Países y regiones de almacenamiento y procesamiento; si permite elegir región. | Sabes en qué jurisdicción queda el dato y si hay transferencia internacional que documentar. |
| DPA | Acuerdo publicado y firmable, con cláusulas de transferencia internacional. | Existe, es firmable y nombra a los subencargados. En proveedores críticos: firmado, no ofrecido. |
| Aviso de incidente | Plazo comprometido para avisarte una brecha, vía de aviso, y si está en el DPA. | Hay un número de horas por escrito y contractual. Sin plazo fijado, no puedes cumplir el tuyo. |
| Incidentes públicos | Brechas que el propio proveedor haya publicado, con fecha y alcance. | Los declara y explica qué cambió después. El silencio no equivale a ausencia de incidentes. |
| Continuidad | SLA, página de estado, RTO/RPO declarados, plan de continuidad y pruebas de restauración. | Los objetivos declarados son compatibles con los tuyos para ese proceso. |
| Contacto de seguridad | security.txt, política de divulgación, programa de recompensas. | Hay un canal público para reportar una vulnerabilidad y un compromiso de respuesta. |
| Uso de IA | Si usa IA, si entrena con datos del cliente, y si permite excluirse. | Lo declara y el opt-out es accionable. Es lo que ISO 42001 obliga a saber de un proveedor. |
11 dimensiones · ISO 27001 A.5.19–A.5.22 · cada hallazgo con fuente citada
El criterio no es uno solo: depende del marco y de la criticidad
Aquí está el error más común al copiar una tabla como la anterior: tratarla como una lista fija. La misma dimensión no pesa igual bajo marcos distintos.
- Bajo Ley 21.719, GDPR o LGPD, el DPA, la lista de subencargados y el lugar de procesamiento son obligatorios: el responsable responde por los encargados de su encargado.
- Bajo ISO 22301, que no gobierna datos personales, el DPA es deseable y lo que no se negocia es la continuidad: si el proveedor deja de estar, tu proceso crítico también.
- Bajo ISO 42001, el uso de IA del proveedor deja de ser un dato de color: tu sistema de IA hereda lo que él haga con los datos.
- Bajo ISO 27001, la cadena de suministro TIC (A.5.21) hace obligatoria la lista de subencargados.
Y hay un segundo eje: la criticidad decide cuánto respaldo hace falta, no qué se pide. Sobre un proveedor crítico, "lo dice mi web" no es diligencia debida — hay que haber visto el documento. Sobre uno de bajo riesgo, la declaración pública alcanza y exigir más es quemar tiempo del equipo en el proveedor equivocado.
Declarado, verificado, ausente — y "no pudimos mirar"
Un expediente que mezcla lo dicho con lo probado convierte una afirmación del proveedor en evidencia de diligencia debida, que es justo lo que un auditor viene a desarmar. Tres niveles, más una distinción que casi siempre falta:
- Declarado — lo dice el proveedor en su propio sitio.
- Verificado — hay un documento o registro de un tercero que lo respalda.
- Ausente — se buscó y no está publicado. Es un hallazgo con fecha, no un vacío.
"No pudimos mirar" no es "no hay nada". Si el sitio no respondió, si la página existe pero no se puede leer, o si la revisión quedó a medias, eso es una revisión incompleta — no un incumplimiento del proveedor. Cargarle a un tercero una falla propia es la forma más rápida de que el expediente pierda credibilidad.
Lo que casi nadie revisa: el flow-down contractual
Supongamos que el proveedor publica su lista completa de subencargados. Transparencia impecable. La pregunta que sigue, y que casi ningún programa hace, es: ¿su contrato lo obliga a exigirles a ellos lo mismo que tú le exiges a él?
Sin esa cláusula de flow-down, la diligencia debida se corta en el primer eslabón. Tú le exiges cifrado, aviso de brecha y control de accesos; él contrata a un cuarto que no tiene ninguna de las tres, y tu responsabilidad legal no se detiene ahí. Es el punto donde la cadena de suministro deja de ser una lista de nombres y pasa a ser una obligación.
Y aplica la misma regla que al resto del expediente: afirmar que el contrato lo exige obliga a citar la cláusula. Un "sí" sin referencia no se sostiene cuando alguien pregunte dónde dice eso.
Cuándo reevaluar: por hecho, no por calendario
La recomendación habitual es reevaluar una vez al año. Está bien como piso y es insuficiente como política: el riesgo de un tercero no cambia en aniversarios.
Los disparadores que importan son hechos:
- El proveedor tuvo un incidente de seguridad.
- Apareció un subencargado nuevo — sobre todo en otra jurisdicción.
- Cambió el acceso a datos, la criticidad del servicio o el alcance del contrato.
- Venció una certificación en la que se apoyaba la evaluación anterior.
Un proveedor de bajo riesgo con cadencia de 24 meses puede sufrir una brecha el lunes, sumar un subencargado en otro país el martes y pasar de "sin acceso a datos" a "acceso total" el miércoles, y su ficha seguir diciendo lo mismo hasta dos años después. La cadencia responde "cada cuánto se mira igual"; no responde "qué pasó desde la última vez".
Qué hacer con el proveedor que no cumple
Un proveedor que no cubre lo que tu marco exige no puede quedar aprobado sin condiciones. Y "aprobado con observaciones" sin nada más es aprobado a secas con una nota al pie. Las salidas reales son cuatro, y tres de ellas obligan a algo:
- Aprobar con condiciones — se contrata, y hay algo que debe cerrar en un plazo, con responsable y fecha.
- Restringir el alcance — entra con acceso recortado hasta que acredite lo que falta. La restricción tiene que estar escrita: si no, nadie puede verificarla ni levantarla después.
- No contratar todavía — primero cierra las brechas.
- Rechazar — no entra. No requiere plan, pero sí motivo escrito: si mañana alguien pregunta por qué se eligió al otro, la respuesta tiene que existir.
Una decisión sin compromiso con dueño y plazo no es una decisión: es una opinión archivada.
Chile y Colombia: qué cambia respecto del material gringo
Casi todo lo que se lee sobre evaluación de proveedores está escrito para ISO 27001, SOC 2, PCI DSS, HIPAA y GDPR. Si operas en la región, hay obligaciones que ese material no menciona.
Chile — Ley 21.719
La relación con un proveedor que trata datos personales por ti es una relación de encargado de tratamiento, y eso trae exigencias concretas: contrato o acto jurídico que la documente, autorización para subencargar, y un plazo de aviso de brecha que te permita cumplir el tuyo con la APDP. Si tu proveedor no fija un plazo de notificación, tu propio plazo legal queda en manos de su buena voluntad. Está desarrollado en las 11 obligaciones de la Ley 21.719 y en la página del marco.
Colombia — Ley 1581
El régimen de habeas data también distingue responsable y encargado, y exige que el responsable garantice que el encargado cumple. La lista de subencargados y el lugar de procesamiento vuelven a ser la pieza que casi nadie tiene a mano. Más contexto en el hub de habeas data.
Un punto práctico para ambos países: la pregunta que desbloquea el resto es siempre la misma — ¿quiénes son los subencargados de tu encargado, y dónde procesan? De esa respuesta salen la transferencia internacional, el DPA y el flow-down. Sin ella, las tres quedan en supuestos.
Próximo paso accionable
Si tienes un inventario de proveedores y ninguna evaluación —que es el punto de partida más común—, el orden que rinde es este:
- Clasifica por criticidad y acceso a datos. No todos merecen la misma profundidad.
- Para los críticos y altos, ve a buscar lo que ya publican antes de mandar un cuestionario.
- Escribe el criterio de aprobado antes de mirar los hallazgos, para no acomodar la vara al resultado.
- Revisa el flow-down en los contratos vigentes. Es donde más huecos van a aparecer.
- Define disparadores por evento, no sólo la cadencia anual.
La automatización quita el cuello de botella —recolectar evidencia, seguir la remediación, programar la reevaluación— pero no reemplaza el juicio sobre aceptar o no un riesgo. Esa parte sigue siendo de una persona, y así debe ser: una plataforma que apruebe proveedores sola convierte la diligencia debida en un sello automático.
Vigía arma el expediente; la decisión sigue siendo tuya
Evidence Automation sobre lo que tus proveedores ya publican, criterios de aprobación por marco y criticidad, subencargados detectados y reevaluación disparada por hechos. Multi-framework: ISO 27001, ISO 22301, ISO 42001, SOC 2, Ley 21.719, GDPR y LGPD.
Evaluar mi preparación