Gestión de riesgo de terceros (TPRM) para startups: el proveedor como su mayor vector de riesgo

Por qué el proveedor es su mayor vector de riesgo

Una fintech o startup B2B construida hoy es, en la práctica, una orquestación de servicios de terceros. El onboarding usa un proveedor de KYC/identidad; el pago pasa por un gateway o BaaS; el correo transaccional, el soporte, la observabilidad, el data warehouse, el CRM y decenas de integraciones vía API procesan, transitan o almacenan datos de sus clientes. Cada uno de esos proveedores es una extensión de su perímetro de seguridad, pero opera fuera de su control directo.

La consecuencia práctica es que su riesgo de violación de datos está, en gran medida, tercerizado. Cuando un proveedor es comprometido, quien necesita notificar al titular, a la ANPD y a los clientes B2B es usted, no él. La LGPD trata al controlador como responsable del tratamiento incluso cuando este ocurre en un operador, y los contratos B2B suelen atribuir a su cliente el derecho de reclamo si el incidente nace en su cadena de proveedores.

El NIST formaliza esa preocupación en el dominio de C-SCRM (Cybersecurity Supply Chain Risk Management), descrito en el SP 800-161r1, y la ISO/IEC 27036 está dedicada exactamente a la seguridad de la información en las relaciones con proveedores. El punto común de esas referencias: el riesgo de terceros no es un anexo de su programa de seguridad, es un pilar de él. Para una startup, ignorar esto significa que el control de acceso, el cifrado y el monitoreo que construyó internamente conviven con proveedores nunca evaluados que tienen acceso a los mismos datos.

El desafío específico de la startup es hacer esto con un equipo reducido. Los programas de TPRM corporativos presuponen equipos dedicados, herramientas caras y ciclos de evaluación largos. Nada de eso es viable cuando la seguridad es una fracción del tiempo del CTO. La buena noticia es que el método escala hacia abajo: lo que cambia no es la estructura, es la profundidad aplicada a cada proveedor.

Inventario de proveedores y datos compartidos: el punto de partida

No existe evaluación ni monitoreo de algo que no sabe que existe. El primer entregable de un TPRM es un inventario vivo de proveedores, y suele revelar sorpresas: herramientas adoptadas por un área sin pasar por seguridad (shadow IT), integraciones antiguas con tokens aún válidos y subprocesadores que heredó sin darse cuenta. El SP 800-161r1 del NIST pone la visibilidad de la cadena como prerrequisito de cualquier control posterior.

El inventario mínimo registra, por proveedor: qué datos se comparten (PII, datos financieros, credenciales, datos de salud), el volumen y la sensibilidad, la base legal de tratamiento bajo la LGPD, el tipo de acceso (lectura, escritura, acceso administrativo, acceso a la infraestructura), si hay subprocesadores y la criticidad para la operación. Esos campos no son burocracia: cada uno determina cuánto esfuerzo de evaluación merece el proveedor.

Con el inventario en mano, aplique tiering. Una clasificación simple en tres niveles funciona bien para una startup. Tier 1: proveedores que procesan datos sensibles de clientes o son críticos para la continuidad del negocio (gateway de pago, KYC, proveedor de cloud, BaaS). Tier 2: proveedores con acceso a datos internos o PII limitada (CRM, soporte, correo transaccional). Tier 3: herramientas sin acceso a dato sensible y baja criticidad. El tier define la profundidad del due diligence y la cadencia de reevaluación.

Mantenga el inventario donde el equipo trabaja, no en una planilla olvidada. Ate la entrada de un nuevo proveedor a un disparador real, como la aprobación de un gasto recurrente o la creación de una nueva integración, para que nada entre en el ambiente sin pasar por el registro.

Cómo evaluar proveedores: cuestionario, SOC 2, ISO y due diligence

La evaluación combina lo que el proveedor declara con la evidencia que consigue comprobar. El cuestionario de seguridad es el instrumento de declaración. En lugar de inventar preguntas, use bases estandarizadas: el SIG (Standardized Information Gathering) de Shared Assessments ofrece versiones core y lite, y el CAIQ (Consensus Assessments Initiative Questionnaire) de la Cloud Security Alliance es fuerte para proveedores cloud. Para Tier 2 y 3, un cuestionario reducido de 15 a 30 preguntas centrado en cifrado, control de acceso, gestión de incidentes y cumplimiento ya entrega el 80% de la señal.

La declaración necesita respaldo. Para proveedores Tier 1, exija evidencia independiente: un informe SOC 2 Type II (que atesta la operación de los controles a lo largo de un período, distinto del Type I, que es una foto puntual) o un certificado ISO/IEC 27001 con el Statement of Applicability. Al leer un SOC 2, no se detenga en la opinión del auditor: verifique el alcance (¿el servicio que usa está cubierto?), el período, los Trust Services Criteria evaluados y, sobre todo, las excepciones descritas y los controles complementarios del usuario (CUECs), las responsabilidades que el informe transfiere de vuelta hacia usted.

El due diligence técnico complementa el papel. Verifique la postura pública: encabezados de seguridad y configuración TLS, presencia de un programa de divulgación de vulnerabilidades o bug bounty, página de estado e historial de incidentes, y la lista de subprocesadores del proveedor. Para proveedores que exponen APIs que usted consume, el OWASP API Security Top 10 es el checklist de referencia para entender las clases de falla que más afectan a las integraciones, desde autorización rota a nivel de objeto (BOLA) hasta consumo irrestricto de recursos.

Documente la decisión, no solo los hallazgos. Toda evaluación termina con un veredicto: aprobar, aprobar con condiciones (por ejemplo, exigir MFA obligatorio o un plazo para corregir una excepción del SOC 2) o rechazar. Registrar el razonamiento lo protege en auditorías futuras y en conversaciones con clientes B2B que piden evidencia de su propio programa de proveedores.

Cláusulas contractuales de seguridad: transformando la expectativa en obligación

La evaluación mide el estado actual; el contrato garantiza el estado futuro. Sin cláusulas de seguridad, no tiene base para exigir la notificación rápida de un incidente, auditar al proveedor o rescindir sin penalidad cuando su postura se degrada. La ISO/IEC 27036 trata explícitamente los acuerdos con proveedores como mecanismo de control, y el NIST recomienda fijar requisitos de seguridad en contrato como parte del C-SCRM.

Un conjunto mínimo de cláusulas para proveedores que tocan datos de clientes incluye: notificación de incidente con plazo definido (idealmente en horas, no días, y en línea con los plazos que la ANPD puede exigirle a usted); obligaciones de seguridad baseline (cifrado en tránsito y en reposo, MFA, gestión de vulnerabilidades); derecho de auditoría o, como mínimo, derecho a recibir informes de auditoría como el SOC 2 anualmente; control sobre subprocesadores (aviso previo y derecho de objeción); cláusulas de tratamiento de datos y DPA alineados a la LGPD; y obligaciones de devolución o destrucción de datos al cierre del contrato.

Para una startup sin departamento jurídico robusto, la estrategia es tener un anexo de seguridad (security addendum o DPA) estandarizado que se adjunta a los contratos, en lugar de negociar desde cero con cada proveedor. Priorice la batalla contractual por los proveedores Tier 1: es donde la notificación de incidente y el derecho de auditoría realmente importan. Para proveedores de estantería que no negocian términos, la decisión informada es aceptar conscientemente el riesgo residual y registrarlo, o elegir un competidor que acepte sus términos.

Monitoreo continuo y respuesta a incidente de terceros

La foto que tomó en el onboarding envejece. El SOC 2 cubre un período pasado y expira; los proveedores agregan subprocesadores, cambian el alcance, sufren incidentes y a veces se deterioran en silencio. Por eso el NIST y la ISO 27036 tratan la relación con el proveedor como un ciclo de vida, no un evento único. El monitoreo continuo es lo que mantiene su inventario conectado a la realidad entre una reevaluación y otra.

En una operación reducida, el monitoreo continuo no significa un SOC dedicado a cada proveedor. Significa establecer disparadores: reevaluación periódica calibrada por tier (anual para Tier 1, más espaciada para los demás), renovación de evidencia (cobrar el nuevo SOC 2 cuando el anterior expira), seguimiento de páginas de estado y boletines de seguridad de los proveedores críticos, alertas de exposición pública (credenciales filtradas, cambios de postura) y revisión de la lista de subprocesadores. Un inventario con fecha de la última evaluación y fecha de validez de la evidencia convierte el monitoreo en una fila de tareas, no en una vigilancia permanente.

La respuesta a incidente de terceros necesita estar en su plan antes de que ocurra. Cuando un proveedor avisa que fue comprometido, el reloj regulatorio y contractual ya está corriendo. Tenga definido: quién recibe y triagea el aviso, cómo determina si sus datos fueron afectados, sus propias obligaciones de notificación (ANPD, titulares, clientes B2B), cómo contener el acceso del proveedor afectado (revocar tokens y claves de API) y cómo comunicar. El playbook de incidente de su startup debe tener una rama explícita para 'el incidente fue en el proveedor', porque la mecánica es distinta de un incidente interno.

Es exactamente en ese ciclo donde Decripte actúa como socio de startups y fintechs: evaluación de proveedores (cuestionario, lectura de SOC 2/ISO y due diligence), monitoreo continuo de la postura de terceros y soporte al cumplimiento por la línea de Seguridad Normativa. Y el plan gratuito de Gestión de Amenazas da visibilidad inicial sobre las exposiciones de su ambiente y de su superficie externa, un buen punto de partida para quien aún está estructurando el programa. Hable con nosotros para diseñar un TPRM proporcional al tamaño de su equipo.

Checklist práctico

1. 1

   1. Arme el inventario de proveedores y datos

   Liste todo proveedor SaaS, API y prestador que procesa, transita o almacena datos. Para cada uno, registre los datos compartidos, el tipo de acceso, la base legal LGPD, los subprocesadores y la criticidad. Incluya el shadow IT que aparezca.

2. 2

   2. Clasifique por criticidad (tiering)

   Separe en Tier 1 (datos sensibles de clientes o crítico para la operación), Tier 2 (PII limitada o dato interno) y Tier 3 (sin dato sensible). El tier define la profundidad de la evaluación y la cadencia de reevaluación.

3. 3

   3. Aplique el cuestionario de seguridad

   Use bases estandarizadas (SIG de Shared Assessments, CAIQ de la CSA) en lugar de inventar preguntas. Use versiones reducidas para Tier 2 y 3, centrándose en cifrado, control de acceso, gestión de incidentes y cumplimiento.

4. 4

   4. Exija y lea evidencia independiente

   Para Tier 1, pida SOC 2 Type II o ISO 27001 con Statement of Applicability. Verifique alcance, período, excepciones y los controles complementarios del usuario (CUECs). Para APIs consumidas, use el OWASP API Security Top 10 como checklist.

5. 5

   5. Fije la seguridad en contrato

   Adjunte un DPA o security addendum estandarizado con notificación de incidente en plazo definido, baseline de seguridad, derecho a informes de auditoría, control de subprocesadores y devolución/destrucción de datos al cierre.

6. 6

   6. Establezca monitoreo continuo

   Defina disparadores: reevaluación por tier, renovación de SOC 2 al expirar, seguimiento de estado y boletines de los proveedores críticos, alertas de exposición y revisión de subprocesadores. Use el inventario con fechas de validez como fila de tareas.

7. 7

   7. Prepare la respuesta a incidente de terceros

   Cree una rama del playbook para incidentes en proveedores: quién triagea el aviso, cómo evaluar el impacto en sus datos, sus obligaciones de notificación (ANPD, titulares, clientes), cómo revocar el acceso (tokens y claves) y cómo comunicar.

Preguntas frecuentes