Saltar al contenido principal

Seguridad y Cumplimiento

Los clientes de servicios financieros no solo quieren video. Necesitan video confiable, conforme y auditable. La seguridad no es una característica — es la base.

Certificaciones requeridas​

SOC 2 Tipo II​

Qué es: Auditoría estándar de la industria para organizaciones de servicio que manejan datos de clientes. Se centra en Seguridad, Disponibilidad, Integridad de procesamiento, Confidencialidad y Privacidad (Criterios de servicios de confianza).

Por qué la necesitamos:

  • Requerida por la mayoría de bancos, AFPs y aseguradoras
  • Demuestra madurez operativa
  • Habilita acuerdos empresariales
  • Muestra compromiso con la protección de datos

Qué requiere:

  • Políticas y procedimientos de seguridad
  • Controles de acceso y monitoreo
  • Plan de respuesta a incidentes
  • Gestión de proveedores
  • Capacitación en seguridad regular
  • Monitoreo y registro continuos

ISO 27001​

Qué es: Estándar internacional para sistemas de gestión de seguridad de la información (SGSI).

Por qué la necesitamos:

  • Reconocida globalmente (especialmente importante en LATAM)
  • Requerida por muchas empresas
  • Demuestra un enfoque sistemático hacia la seguridad
  • Ventaja competitiva frente a competidores regionales

Qué requiere:

  • Documentación formal del SGSI
  • Metodología de evaluación de riesgos
  • Implementación de controles de seguridad (cifrado, control de acceso, etc.)
  • Auditorías y revisiones regulares
  • Compromiso de la dirección

Nuestro cronograma:

  1. Año 1: Construir la base del SGSI mientras se trabaja en SOC 2
  2. Año 2 Q1-Q2: Análisis de brechas y remediación
  3. Año 2 Q3: Auditoría externa
  4. Año 2 Q4: Certificación obtenida

GDPR​

Qué es: El Reglamento General de Protección de Datos de la Unión Europea — el estándar global de referencia para la protección de datos personales. Aunque Percus opera principalmente en LATAM, el cumplimiento del GDPR es un requisito de facto porque muchos clientes enterprise tienen operaciones europeas, y las leyes de protección de datos de LATAM (Chile Ley 19.628, Perú Ley 29733, Brasil LGPD) están directamente modeladas en él.

Por qué lo necesitamos:

  • Requerido por clientes enterprise con operaciones en la UE o sujetos de datos europeos
  • Los reguladores de LATAM se alinean cada vez más con los estándares del GDPR
  • Fortalece la confianza en todos los mercados
  • Demuestra el más alto estándar internacional de protección de datos

Qué requiere:

  • Base legal para el tratamiento de datos personales (consentimiento, contrato, interés legítimo)
  • Derecho de acceso, rectificación, supresión ("derecho al olvido") y portabilidad de datos
  • Notificación de brechas de datos dentro de 72 horas
  • Evaluaciones de Impacto de Protección de Datos (DPIA) para tratamientos de alto riesgo
  • Acuerdos de Procesamiento de Datos (DPA) con todos los subprocesadores
  • Privacidad por diseño y por defecto

Nuestra implementación:

  • Tracking de consentimiento integrado en el pipeline de datos de clientes
  • Flujo de DSAR (Solicitud de Acceso de Sujeto de Datos) con eliminación automatizada de datos
  • Plantillas de DPA listas para acuerdos con clientes y subprocesadores
  • Privacidad por diseño aplicada a nivel de arquitectura (renderizado del lado del cliente, sin PII en servidores)
  • Runbook de respuesta a brechas con capacidad de notificación en 72 horas

PCI DSS (Si se manejan datos de pago)​

Qué es: Estándar de seguridad de datos de la industria de tarjetas de pago para el manejo de información de tarjetas de crédito.

¿Lo necesitamos?

  • No inmediatamente (no procesamos pagos directamente)
  • Potencialmente más adelante si manejamos videos de confirmación de pago con datos de tarjetas
  • Se puede evitar nunca tocando números de tarjetas (usar referencias tokenizadas)

Decisión: Diseñar los sistemas para evitar el alcance PCI (usar tokens provistos por el banco, no datos de tarjeta en bruto).

Cumplimiento regional​

Chile: Ley 19.628 (Protección de Datos Personales)​

Requisitos:

  • Consentimiento explícito para el tratamiento de datos personales
  • Derecho de acceso, modificación y eliminación de datos
  • Minimización de datos (recolectar solo lo necesario)
  • Almacenamiento y transmisión seguros

Nuestra implementación:

  • Tracking de consentimiento en la base de datos de clientes
  • Políticas de retención de datos (eliminación automática tras la campaña)
  • Cifrado en reposo y en tránsito
  • Flujo de solicitud de acceso de sujeto de datos (DSAR)

Perú: Ley 29733 (Protección de Datos Personales)​

Similar a Chile, con adiciones:

  • Notificación de brechas de datos (5 días hábiles)
  • Restricciones para transferencias transfronterizas de datos
  • Registro ante la autoridad nacional (requerido para controladores de datos)

Nuestra implementación:

  • Región AWS São Paulo para residencia de datos en LATAM
  • Plan de respuesta a brechas con plantillas de notificación
  • Asesoría legal para cumplimiento transfronterizo

Consideraciones generales para LATAM​

Leyes de secreto bancario: La mayoría de los países de LATAM tienen regulaciones estrictas de secreto bancario (ej. la Ley General de Bancos de Chile). Los datos financieros deben protegerse con seguridad de grado bancario.

Nuestro enfoque:

  • Tratar todos los datos financieros como altamente sensibles
  • Cifrar todo (datos en reposo, en tránsito y en uso cuando sea posible)
  • Controles de acceso con principio de necesidad de conocer
  • Trazabilidades completas para investigaciones regulatorias

Principios de implementación de seguridad​

Estos no son solo ítems de una lista de verificación. Son requisitos siempre activos en cada línea de código que escribimos.

1. Cifrado en todas partes​

En reposo:

  • AWS S3 con cifrado del lado del servidor (SSE-KMS)
  • Bases de datos RDS cifradas
  • Volúmenes EBS cifrados
  • Secrets Manager para claves API y credenciales

En tránsito:

  • TLS 1.3 para todas las conexiones externas
  • mTLS para comunicación interna entre microservicios
  • Aislamiento VPC para servicios sensibles
  • Sin endpoints públicos para el procesamiento de datos

En uso (donde sea posible):

  • Cifrado del lado del cliente para datos altamente sensibles
  • AWS Nitro Enclaves para el procesamiento de PII cuando sea necesario

2. Arquitectura Zero Trust​

Principio: Nunca confiar, siempre verificar. Cada solicitud es autenticada y autorizada.

Implementación:

  • Sin confianza implícita entre servicios
  • Autenticación servicio-a-servicio mediante roles IAM o tokens JWT
  • Segmentación de red (subredes pública/privada/datos)
  • Principio de mínimo privilegio (permisos mínimos necesarios)

Ejemplo: El servicio de renderizado de video no puede acceder directamente a la base de datos de clientes. Solicita datos a través de una API autenticada, que valida la solicitud, verifica los permisos, registra el acceso y devuelve solo los datos mínimos necesarios.

3. Registro de auditoría integral​

Qué registramos:

  • Cada acceso a datos (quién, qué, cuándo, por qué)
  • Cada llamada a la API (origen, hash del payload, estado de respuesta)
  • Cada video generado (template, fuentes de datos, destinatario)
  • Cada intento de autenticación (éxito y fallo)
  • Cada cambio de configuración (quién modificó qué)

Dónde:

  • AWS CloudTrail (logs de auditoría de API)
  • Logs de aplicación → CloudWatch Logs
  • Eventos de seguridad → AWS Security Hub
  • Archivo a largo plazo → S3 Glacier (retención de 7 años para servicios financieros)

Por qué:

  • Las auditorías regulatorias requieren prueba del manejo de datos
  • La respuesta a incidentes necesita logs detallados
  • Los clientes necesitan evidencia para sus auditores

4. Control de acceso y autenticación​

Para el personal de Percus:

  • SSO con MFA (obligatorio, sin excepciones)
  • Tokens de acceso de duración limitada (1 hora de expiración)
  • Control de acceso basado en roles (RBAC)
  • Acceso just-in-time para producción (requiere aprobación)
  • Revisiones de acceso trimestrales

Para clientes:

  • Autenticación de API mediante OAuth 2.0 o claves de API
  • Claves de cifrado por cliente (datos de clientes aislados)
  • Lista de IPs permitidas para operaciones sensibles
  • Firmas de webhook para callbacks

Para el procesamiento de datos:

  • Cuentas de servicio con roles IAM (sin credenciales de larga duración)
  • Rotación de secretos (máximo 90 días)
  • Variables de entorno cifradas

5. Minimización y retención de datos​

Recolectar solo lo necesario:

  • No solicitar perfiles completos de clientes si solo se necesita nombre + saldo
  • Hashear o tokenizar identificadores cuando sea posible
  • Agregar datos para analíticas (sin PII en bruto)

Eliminar cuando se termine:

  • Datos en bruto de clientes eliminados tras la generación del video (máximo 30 días de retención)
  • Videos generados almacenados según la política de retención del cliente (típicamente 1-2 años)
  • Logs de auditoría retenidos más tiempo (7 años para cumplimiento en servicios financieros)

Derecho al olvido:

  • Endpoint de API para solicitudes de eliminación de datos
  • Flujo automatizado para purgar datos en todos los sistemas
  • Reporte de confirmación para los equipos de cumplimiento del cliente

6. Plan de respuesta a incidentes​

Detección:

  • Alertas automáticas para patrones de acceso anómalos
  • AWS GuardDuty para detección de amenazas
  • Integración con SIEM (Gestión de Información y Eventos de Seguridad)
  • Escaneos de vulnerabilidad regulares

Respuesta:

  • Runbooks de respuesta a incidentes (pasos predefinidos)
  • Rotación de guardia (cobertura 24/7)
  • Plantillas de comunicación (notificación al cliente, notificación al regulador)
  • Revisión post-incidente (sin culpas, enfocada en mejoras)

Tiempos:

  • Detección → Respuesta: menos de 15 minutos para incidentes críticos
  • Notificación al cliente: menos de 2 horas para brechas de datos
  • Notificación al regulador: según la ley local (típicamente 72 horas)

7. Ciclo de vida de desarrollo seguro (SDL)​

Seguridad del código:

  • Análisis estático (SonarQube, CodeQL)
  • Escaneo de dependencias (Snyk, Dependabot)
  • Escaneo de secretos (GitGuardian, TruffleHog)
  • Hooks pre-commit (prevenir secretos en git)

Proceso de revisión:

  • Revisión de código obligatoria para todos los cambios
  • Revisión de seguridad para cambios de alto riesgo (manejo de datos, auth, cifrado)
  • Pruebas de penetración antes de lanzamientos mayores

Despliegue:

  • Infraestructura inmutable (sin cambios manuales)
  • Infraestructura como código (Terraform, revisada en git)
  • Rollback automatizado ante alertas de seguridad

Monitoreo de cumplimiento y mejora continua​

Trimestral:

  • Auditoría interna de seguridad
  • Revisión de accesos (eliminar cuentas no utilizadas)
  • Evaluación de seguridad de proveedores
  • Capacitación en seguridad para todo el personal

Anual:

  • Prueba de penetración externa
  • Re-auditoría SOC 2 (tras la primera certificación)
  • Análisis de brechas de cumplimiento
  • Simulacro de recuperación ante desastres

Continuo:

  • Monitoreo automatizado de seguridad
  • Parcheo de vulnerabilidades (menos de 7 días para críticas)
  • Dashboard de métricas de seguridad (para dirección)

Funcionalidades de seguridad para clientes​

Reportes de seguridad:

  • Reporte mensual de postura de seguridad (para clientes enterprise)
  • Exportación de logs de auditoría (para equipos de cumplimiento del cliente)
  • Resultados de pruebas de penetración (sanitizados, compartidos bajo solicitud)

Opciones de residencia de datos:

  • AWS São Paulo (Brasil) para datos de LATAM
  • Backup multi-región para recuperación ante desastres
  • Solicitudes de región específica por cliente (donde sea factible)

Documentación de cumplimiento:

  • Reporte SOC 2 (compartido bajo NDA)
  • Certificado ISO 27001 (público)
  • Respuestas a cuestionarios de seguridad (estandarizadas)
  • Plantillas de DPA (Acuerdo de Procesamiento de Datos)

Por qué importa​

Para los clientes:

  • Confianza de que los datos de sus clientes están seguros
  • Evidencia para sus auditores
  • Menor riesgo en las relaciones con proveedores

Para Percus:

  • Ventaja competitiva (muchas plataformas de video en LATAM carecen de certificaciones)
  • Mayor valor de contratos (las empresas pagan por seguridad)
  • Ciclos de venta más rápidos (lista de verificación de seguridad pre-respondida)

Para ingeniería:

  • Pautas claras para construir funcionalidades
  • Sin sorpresas durante las auditorías
  • Orgullo de construir sistemas confiables

Conclusión clave​

La seguridad no es una casilla. Es una cultura.

Cada ingeniero, diseñador y PM debe pensar en la protección de datos. Cada funcionalidad necesita revisión de seguridad. Cada despliegue necesita registro de auditoría.

Manejamos el futuro financiero de las personas. Estados de cuenta de pensiones. Reclamos de seguros. Reportes de crédito. Eso es una confianza sagrada.

No tomamos atajos. No lanzamos rápido y corregimos después. Lo hacemos bien desde el principio.

Ese es el estándar de Percus.