TRPA Docs
Los Third-Party Risk Assessments (TPRA) son evaluaciones que algunos clientes realizan antes de contratar o habilitar a /nk como proveedor. Su objetivo es entender nuestras prácticas de seguridad, identificar potenciales riesgos y validar los controles que aplicamos sobre información, accesos, desarrollo y operación.
Para evitar generar documentación desde cero ante cada evaluación, mantenemos un conjunto de políticas estándar de /nk que pueden ser utilizadas como evidencia durante estos procesos.
Importante: estos documentos describen prácticas que /nk debe cumplir realmente. Si un TPRA requiere un control, certificación o proceso que no tenemos implementado, debemos declararlo correctamente y evaluar si corresponde implementarlo. No debemos modificar documentación únicamente para satisfacer una respuesta del cuestionario.
Documentos disponibles
Information Security Policy
Política general de seguridad de la información de /nk. Define los principios y prácticas para proteger la confidencialidad, integridad y disponibilidad de la información, incluyendo accesos, dispositivos, manejo de datos, desarrollo seguro e incidentes.
Access Control Policy
Define cómo se otorgan, revisan y revocan accesos a sistemas, aplicaciones y datos. Incluye principios de least privilege, acceso basado en roles, MFA, revisiones periódicas y offboarding.
Acceptable Use Policy
Establece las reglas para el uso responsable de dispositivos, cuentas, sistemas y recursos digitales de /nk por parte de empleados, contractors y colaboradores.
Password Policy
Define los requisitos para creación, almacenamiento y gestión de contraseñas, incluyendo longitud mínima, uso de Keeper, credenciales únicas y Multi-Factor Authentication.
Vulnerability Management Policy
Describe cómo identificamos, evaluamos, priorizamos y corregimos vulnerabilidades en aplicaciones, código y dependencias, incluyendo dependency scanning, seguimiento y criterios de remediación.
Risk Management Policy
Define el proceso utilizado para identificar, evaluar, tratar y monitorear riesgos operativos, tecnológicos, de seguridad, compliance y terceros.
Security Incident Management Policy
Establece cómo detectar, reportar y responder ante incidentes de seguridad. Define las etapas de identificación, contención, erradicación, recuperación, comunicación y documentación posterior.
Documentos específicos de proyecto
Además de las políticas generales, algunos TPRAs pueden requerir evidencia específica del proyecto. Estos documentos no deberían reutilizarse automáticamente entre clientes, ya que dependen de la arquitectura y alcance de cada solución.
Ejemplos:
- Data Flow Diagram (DFD): representa qué sistemas participan, qué información circula entre ellos y qué parte es responsabilidad de /nk, del cliente o de terceros.
- Web Application Vulnerability Scan Report: resultado de un análisis de vulnerabilidades realizado sobre la aplicación correspondiente. Cuando aplique, debe realizarse sobre el proyecto evaluado y normalmente antes del go-live.
- Architecture / Infrastructure Diagram: puede ser solicitado cuando /nk gestiona infraestructura o cuando la arquitectura del proyecto requiere mayor detalle.
- Additional Evidence: dependiendo del cliente, pueden solicitarse evidencias de access reviews, dependency scanning, incident management u otros controles.
Certificaciones y reportes externos
Algunos TPRAs solicitan certificaciones o auditorías como SOC 2 Type II, ISO/IEC 27001, penetration tests o Network Vulnerability Scan Reports.
Estos documentos no deben confundirse con nuestras políticas internas. Si /nk no cuenta con una certificación o reporte solicitado, debemos indicarlo de forma transparente y explicar los controles que sí tenemos implementados y, cuando corresponda, por qué el requerimiento no aplica al alcance del servicio.
Al completar un TRPA
Las respuestas deben darse siempre desde dos perspectivas: primero, las prácticas y controles generales de /nk como proveedor; segundo, el alcance específico del proyecto cuando la pregunta dependa de la solución que estamos construyendo.
Antes de responder No o N/A, validar si la pregunta se refiere a /nk como organización o exclusivamente al servicio del cliente. Muchos cuestionarios son evaluaciones del vendor, aunque el proyecto particular no requiera ese control.