Arquitectura de seguridad

Tratamiento de sus datos de extremo a extremo:

• Aislamiento multitenant: cada consulta a base de datos se acota por organization_id en la capa ORM; las pruebas de integración verifican que las consultas cross-tenant no devuelven filas. Sin acceso SQL en bruto para el código de aplicación.

• Registro de auditoría: cada mutación administrativa (crear / actualizar / eliminar colaborador, turno, fichaje, cambio de facturación) se registra con actor, objetivo, valores antes/después, dirección IP y marca temporal. Retención por nivel: 7 días (Free) / 1 año (Starter+) / 3 años (Pro+).

• Backups: snapshots automatizados de RDS diarios, retenidos 30 días; recuperación point-in-time a cualquier segundo dentro de la ventana de retención. Las restauraciones se prueban trimestralmente conforme al runbook de recuperación ante desastres.

• Flujo de derecho de supresión: las solicitudes RGPD / CCPA fluyen por /admin/identity/users — anonimizan PII de colaboradores (nombre, correo, teléfono, plantilla biométrica) preservando los registros agregados de fichaje que el responsable del tratamiento (su organización) necesita para cumplimiento laboral. Mecanismo completo en la Política de Privacidad §4.

• Datos biométricos (reconocimiento facial para fichar): se recopilan únicamente con consentimiento explícito del colaborador en el primer uso (art. 9.2.a) del RGPD). Las plantillas faciales se almacenan como hashes unidireccionales — la imagen original no se conserva. Los administradores de organización pueden desactivar el reconocimiento facial globalmente en Reglas de Fichaje; el consentimiento puede retirarse en cualquier momento desde el perfil del colaborador.

Cómo operamos la seguridad como función:

• Práctica de ingeniería: cada cambio de código pasa por revisión de pull request con al menos un revisor que apruebe. Los cambios relevantes para seguridad (auth, cifrado, IAM) requieren un revisor designado de seguridad adicional.

• Gestión de dependencias: Python con Poetry y versiones bloqueadas; JavaScript con lockfile de Bun. Las dependencias vulnerables se exponen vía GitHub Dependabot y se atienden por orden de prioridad.

• Control de acceso: el acceso a producción es solo lectura por defecto; el acceso de escritura requiere ticket de cambio documentado. La baja de ingenieros revoca todos los accesos en 24 horas tras la salida.

• Respuesta a incidentes: un runbook interno cubre identificación → contención → erradicación → recuperación → revisión post-incidente. Los incidentes de Severidad 1 desencadenan un compromiso de notificación al cliente en 24 horas (Política de Privacidad §6).

• Revisión de seguridad de proveedores: cada nuevo subencargado (actualmente 5 listados en /trust/sub-processors) pasa por una revisión documentada — DPA en vigor, cuestionario de seguridad revisado, alcance de datos minimizado.

Nos comprometemos con una hoja de ruta pública y fechada en lugar de afirmaciones retroactivas. Progreso en directo:

• SOC 2 Type II — META T1 2027. Aún no certificado. Vanta + A-LIGN seleccionados (decisión registrada el 24/05/2026). Cronología pública de 8 hitos en /trust/soc2; informe emitido en T3 2027.

• Arquitectura preparada para RGPD — auditoría de privacidad Wave 1-4 completada (minimización de datos, derecho de supresión, puertas de consentimiento, tratamiento biométrico bajo el art. 9). No certificada formalmente por un regulador (el RGPD no cuenta con organismo de certificación formal); proporcionamos nuestro DPA bajo solicitud en /trust/dpa.

• ISO 27001 — AÚN NO INICIADO. Puede seguir a SOC 2 en 2027 o 2028 según la demanda de prospectos enterprise UE.

• Específicas de sector (HIPAA / PCI-DSS / FedRAMP) — FUERA DE ALCANCE hoy. svdy se enfoca en gestión de personal SMB; PHI de salud / datos de tarjetas / cargas de trabajo del gobierno federal quedan fuera de nuestro caso de uso hasta que se incluyan explícitamente.