Política de Seguridad de la Información

Esta Política de Seguridad de la Información describe las certificaciones que posee Didit, los controles técnicos y organizativos que opera Didit, y los artefactos de confianza disponibles para clientes, clientes potenciales, reguladores y auditores. Se revisa al menos cada seis meses.

• Contacto de seguridad: security@didit.me
• Delegado de Protección de Datos: dpo@didit.me
• Página de estado (en tiempo real): status.didit.me
• Paquete de confianza (bajo NDA): envía un correo electrónico a security@didit.me

1. Certificaciones y acreditaciones

Para solicitar cualquiera de los informes o certificados subyacentes, envía un correo electrónico a security@didit.me. Los informes restringidos bajo los términos de su emisor (por ejemplo, SOC 2 Tipo 1) se comparten después de un Acuerdo de Confidencialidad (NDA) firmado, el mismo día hábil.

2. Alcance

Esta política cubre a todo el personal de Didit (empleados, contratistas y terceros autorizados), todos los sistemas de información de producción y corporativos de Didit, y los Servicios orientados al cliente descritos en los Términos y Condiciones Comerciales. Está respaldada por la Declaración de Aplicabilidad que sustenta el sistema de gestión ISO/IEC 27001:2022 de Didit.

3. Gobernanza

• Sistema de Gestión de Seguridad de la Información y Privacidad alineado con los controles ISO/IEC 27001:2022 e ISO/IEC 27701, con una Declaración de Aplicabilidad documentada.
• El Director de Tecnología es el patrocinador ejecutivo de seguridad de la información; el Delegado de Protección de Datos (dpo@didit.me) es el responsable de la gobernanza del programa de privacidad.
• Auditoría de seguridad externa anual por auditores independientes (auditorías de vigilancia ISO 27001 y exámenes SOC 2).
• Registro de riesgos revisado y actualizado trimestralmente. Los riesgos materiales se escalan al comité de dirección.
• Mejora continua, cada incidente, hallazgo de auditoría y evaluación de riesgos alimenta el backlog de acciones correctivas y la próxima actualización de la política.

4. Cifrado y gestión de claves

• En reposo: AES-256 en cada base de datos de producción, almacén de objetos y volumen de copia de seguridad.
• En tránsito: TLS 1.3 para cada llamada a la API externa, webhook y sesión de la Consola de Negocio. Las versiones TLS antiguas y los cifrados débiles están deshabilitados. HTTP Strict Transport Security (HSTS) se aplica en todo el sitio y se precarga.
• Gestión de claves: AWS Key Management Service (KMS) almacena y rota las claves. El código de la aplicación nunca toca el material de clave sin procesar. Las claves de sandbox y producción están completamente separadas.
• Hashing: las credenciales de los clientes se hash con funciones adaptativas estándar de la industria (bcrypt o equivalente). Las claves API se almacenan como hashes unidireccionales; el valor sin procesar se muestra al operador solo en el momento de la creación.

5. Identidad, acceso y arquitectura de confianza cero

• Confianza cero por defecto, cada solicitud a cada sistema interno está autenticada y autorizada. No hay confianza implícita basada en la ubicación de la red.
• Control de acceso basado en roles (RBAC) con el principio de mínimo privilegio. Las revisiones de acceso se realizan trimestralmente.
• La Autenticación Multifactor (MFA) es obligatoria para cada empleado, cada sistema de producción, cada consola en la nube y cada cuenta de alojamiento de código.
• Inicio de Sesión Único (SSO) para aplicaciones internas, con MFA de token de hardware para roles privilegiados.
• Acceso Just-in-Time para producción: el acceso privilegiado permanente es la excepción, no la regla.
• Registro de auditoría, cada acción privilegiada se registra en un pipeline de auditoría inalterable y de solo escritura que se conserva durante al menos 12 meses.

6. Residencia y segregación de datos

• Unión Europea por defecto. Los datos de producción se procesan y almacenan en la Unión Europea en Amazon Web Services. La residencia específica por región o país está disponible en contratos Enterprise, sujeta a disponibilidad, para jurisdicciones cuyos reguladores lo requieran.
• Separación de entornos. Sandbox, staging y producción están aislados a nivel de red, identidad y gestión de claves. Ningún humano o servicio en un entorno puede leer datos en otro sin una ruta de acceso explícita y auditada.
• Separación de inquilinos. Los datos multi-inquilino se separan lógicamente con claves de cifrado por inquilino cuando corresponda. Las consultas entre inquilinos se bloquean a nivel de aplicación y base de datos.

7. Ciclo de vida de desarrollo seguro (SDLC)

• La revisión de código es obligatoria para cada cambio de producción. Ningún ingeniero puede fusionar código sin revisar en producción.
• Static Application Security Testing (SAST), escaneo de dependencias y Software Composition Analysis (SCA) se ejecutan automáticamente en cada pull request.
• Escaneo de contenedores e infraestructura en cada compilación y en un horario recurrente para imágenes desplegadas.
• Pruebas de seguridad pre-producción para cambios de alto impacto (autenticación, gestión de claves, pipelines biométricos, flujos de pago).
• Pruebas de penetración internas continuamente; pruebas de penetración externas al menos una vez al año por especialistas independientes. Los hallazgos materiales se rastrean hasta su cierre en un cronograma vinculado al SLA.
• Canal de recompensas por errores / divulgación responsable, informa problemas de seguridad a security@didit.me.

8. Gestión de vulnerabilidades

• SLA de parcheo por gravedad, crítico (dentro de las 72 horas de la divulgación del proveedor), alto (dentro de los 7 días), medio (dentro de los 30 días), bajo (dentro de los 90 días).
• Escaneo continuo de vulnerabilidades en toda la infraestructura de producción, contenedores y dependencias.
• Modelado de amenazas para nuevas superficies de productos, pipelines biométricos e integraciones entre entornos.

9. Monitoreo, detección y respuesta a incidentes

• Monitoreo 24x7 de cada sistema de producción con alertas sobre disponibilidad, errores y señales de seguridad.
• Security Information and Event Management (SIEM) agrega y correlaciona eventos de seguridad; los patrones anormales se escalan a los ingenieros de seguridad de guardia.
• Plan de Respuesta a Incidentes Documentado con roles designados, árbol de comunicación, matriz de gravedad y proceso de revisión post-incidente. El plan se prueba al menos anualmente mediante ejercicios de mesa.
• Notificación de violación de datos personales. Didit notifica a los clientes afectados sin demora indebida y, en cualquier caso, a tiempo para permitir que los clientes cumplan con su propia obligación de notificación de 72 horas según el Artículo 33 del Reglamento General de Protección de Datos (RGPD). Los clientes Enterprise reciben un ingeniero de guardia designado y un canal de comunicación dedicado.
• Página de estado pública en status.didit.me, cada incidente de producción, cada análisis post-mortem, sin necesidad de iniciar sesión.

10. Continuidad del negocio y recuperación ante desastres

• Redundancia activa multi-AZ en cada región de producción; conmutación por error automática para servicios sin estado.
• Las copias de seguridad están cifradas, separadas geográficamente dentro del límite de residencia elegido y probadas en un horario recurrente.
• Objetivo de Punto de Recuperación (RPO) ≤ 1 hora y Objetivo de Tiempo de Recuperación (RTO) ≤ 4 horas para la API de verificación central y la Consola de Negocio.
• Pruebas de Recuperación ante Desastres (DR) al menos anualmente.

11. Seguridad del personal

• Verificaciones de antecedentes a cada empleado y contratista con acceso a datos de producción o datos personales, cuando lo permita la ley aplicable.
• Acuerdos de confidencialidad al contratar a cada empleado y contratista.
• Formación obligatoria en seguridad y privacidad al incorporarse y actualizada al menos anualmente para cada empleado. Formación específica (codificación segura, manejo de datos biométricos, antifraude, antilavado de dinero) para los roles que lo necesiten.
• Simulaciones de phishing en un horario recurrente.
• El proceso de incorporación / cambio de rol / desvinculación revoca el acceso dentro de las 24 horas siguientes al cambio de rol o la salida.

12. Gestión de proveedores y subencargados

• Cada subencargado es evaluado en cuanto a riesgos antes de su incorporación y reevaluado al menos anualmente.
• Cada subencargado firma un Acuerdo de Tratamiento de Datos (DPA) que impone obligaciones de protección de datos sustancialmente similares a las que Didit debe a sus propios clientes.
• La lista actual de subencargados se comparte con clientes y clientes potenciales por correo electrónico después de firmar un Acuerdo de Confidencialidad (NDA). Envía un correo electrónico a security@didit.me para solicitarla. Los clientes suscritos a las notificaciones de cambio de subencargados son notificados por correo electrónico con suficiente antelación para oponerse.

13. Derechos del interesado y eliminación de datos

• Derecho de acceso y portabilidad, `GET /v3/sessions/:session_id/decision/`.
• Derecho de supresión, `POST /v3/sessions/:session_id/delete/`. Elimina la sesión y todos los artefactos vinculados en cada réplica.
• La retención por aplicación es configurable en la Consola de Negocio entre 30 días y 10 años; el valor predeterminado es indefinido a menos que el cliente configure un período más corto. La retención de datos biométricos está en todos los casos sujeta a, y limitada por, las leyes y regulaciones de privacidad biométrica aplicables, incluido el Artículo 9 del Reglamento General de Protección de Datos (RGPD) de la UE, la Ley de Privacidad de Información Biométrica de Illinois (BIPA), la Ley de Captura o Uso de Identificadores Biométricos de Texas (CUBI), la Ley H.B. 1493 de Washington y cualquier otra ley de privacidad biométrica aplicable; cuando dicha ley prescriba un período de retención más corto o una obligación de destrucción anterior, esa regla más corta o más estricta prevalecerá sobre cualquier período de retención predeterminado o configurado por el cliente.
• Consulta la Política de Privacidad y el Aviso de Privacidad de Verificación para conocer el proceso completo de derechos del interesado.

14. Notificación de un problema de seguridad

Si crees que has encontrado una vulnerabilidad de seguridad en cualquier producto o servicio de Didit, envía un correo electrónico a security@didit.me con una descripción, los pasos para reproducirla y el impacto que observaste. Didit acusa recibo de los informes de seguridad en un plazo de 2 días hábiles y trabaja de buena fe con los informantes que siguen prácticas de divulgación responsable.

15. Contacto

• Seguridad: security@didit.me
• Delegado de Protección de Datos: dpo@didit.me
• Privacidad: privacy@didit.me
• Legal / contratos: legal@didit.me
• Solicitud de paquete de confianza (bajo NDA): security@didit.me