Esquema Nacional de Seguridad — Nivel Básico (RD 311/2022)
Declaración Formal de Conformidad
Deep-Check declara que su sistema de verificación de identidad biométrica, disponible en deep-check.vercel.app, cumple con los controles aplicables del Esquema Nacional de Seguridad (ENS) nivel Básico, conforme al Real Decreto 311/2022 de 3 de mayo, en la fecha indicada en este documento. Esta autodeclaración está disponible públicamente y será actualizada ante cambios sustanciales en el sistema.
| Nombre del sistema | Deep-Check — Plataforma de Verificación Biométrica |
| Versión | 1.0 (febrero 2026) |
| Responsable | Deep-Check (organización declarante) |
| Categoría ENS | Básico (RD 311/2022, Anexo I) |
| Ámbito | Aplicación web SaaS de verificación de identidad mediante biometría conductual y análisis forense documental |
| URL | https://deep-check.vercel.app |
| Infraestructura | Vercel (frontend/API, Edge Runtime) + Supabase (base de datos, UE) |
| Clasificación datos | Datos biométricos (categoría especial, RGPD Art. 9) |
| Fecha declaración | 25 de febrero de 2026 |
| Próxima revisión | 25 de agosto de 2026 (revisión semestral) |
Los controles parcialmente implementados corresponden a procedimientos operativos en proceso de formalización (op.exp.4 política de actualizaciones, op.exp.8 escalación de incidentes, org.3 procedimientos completos). No afectan a la seguridad técnica del sistema.
| Control | Medida | Implementación | Estado | Evidencia |
|---|---|---|---|---|
| org.1 | Política de seguridad | Política de seguridad documentada en COMPLIANCE.md; publicada en /security | Cumple | /security · COMPLIANCE.md |
| org.2 | Normativa de seguridad | Privacy Policy (/privacy), Terms (/terms) y Security Policy (/security) definen las normas de uso aceptable, protección de datos y divulgación responsable | Cumple | /privacy · /terms · /security |
| org.3 | Procedimientos de seguridad | Procedimientos de gestión de incidentes y divulgación responsable publicados en /security §4; pendiente documentar procedimiento de backup | Parcial | /security §4 |
| org.4 | Proceso de autorización | Consentimiento explícito RGPD Art. 9 requerido antes del tratamiento biométrico; logs de consentimiento almacenados | Cumple | /interview (consent gate) · /enroll (GDPR checkbox) |
| op.pl.1 | Análisis de riesgos | Risk register documentado en COMPLIANCE.md §3; amenazas identificadas: suplantación biométrica, exfiltración de perfiles, ataques de inyección de API | Cumple | COMPLIANCE.md §3 |
| op.pl.2 | Arquitectura de seguridad | Arquitectura publicada en /whitepaper §5 y /security §1: extracción biométrica client-side, transmisión de vectores derivados, almacenamiento pseudonimizado | Cumple | /whitepaper · /security |
| op.acc.1 | Identificación | Candidatos identificados por email y profileId único (ep_*); administradores por sesión token con hash SHA-256 | Cumple | src/app/api/enrollment/route.ts · dc_admin_sessions |
| op.acc.2 | Requisitos de acceso | RLS en Supabase para dc_audit_logs (service_role only); middleware protege /dashboard con cookie httpOnly; API keys de Supabase en variables de entorno | Cumple | src/middleware.ts · Supabase RLS |
| op.acc.5 | Autenticación | Dashboard admin protegido con contraseña + cookie de sesión httpOnly/Secure; comparación con crypto.timingSafeEqual para prevenir timing attacks; tokens de 32 bytes aleatorios | Cumple | src/app/api/auth/dashboard/route.ts · src/middleware.ts |
| op.exp.1 | Inventario de activos | Asset inventory documentado en COMPLIANCE.md §2: codebase (GitHub), base de datos (Supabase EU), frontend (Vercel), modelo ONNX | Cumple | COMPLIANCE.md §2 |
| op.exp.2 | Configuración de seguridad | Rate limiting en middleware (20 rps/IP en /api/ml-score, 5 rps en /api/auth); cabeceras de seguridad completas (CSP, HSTS, X-Frame-Options, Permissions-Policy); security.txt publicado | Cumple | src/middleware.ts · next.config.ts · /security.txt |
| op.exp.4 | Mantenimiento | Dependencias gestionadas con npm audit; actualizaciones mediante CI/CD (Vercel). Pendiente: política de actualización trimestral formal | Parcial | package.json · Vercel CI |
| op.exp.7 | Registro de actividad (audit log) | Audit log completo en dc_audit_logs (Supabase): IPs pseudonimizadas con SHA-256+salt, event_type, endpoint, método HTTP, status_code, duration_ms. Logs en todos los endpoints críticos: /api/ml-score, /api/enrollment, /api/assessments, /api/documents, /api/auth/dashboard | Cumple | src/lib/auditLog.ts · dc_audit_logs (Supabase) · src/middleware.ts |
| op.exp.8 | Registro de gestión de incidentes | Política de divulgación responsable publicada en /security §4 con email de contacto; errores del servidor registrados en Vercel logs y audit log. Pendiente: procedimiento formal de escalación | Parcial | /security §4 · Vercel logs |
| op.ext.1 | Contratación y acuerdos de nivel de servicio | Subencargados documentados: Supabase (UE, ISO 27001), Vercel (SOC 2). Listados en /privacy §7 | Cumple | /privacy §7 |
| op.mon.1 | Detección de intrusiones | Rate limiting detecta y bloquea abuso de API; middleware genera logs estructurados JSON; alertas de Vercel por error 5xx | Cumple | src/middleware.ts · Vercel Analytics |
| mp.com.1 | Perímetro seguro | HTTPS enforced con HSTS (max-age=31536000, includeSubDomains, preload); TLS 1.3 en Vercel y Supabase | Cumple | next.config.ts (HSTS) · Vercel TLS |
| mp.si.1 | Protección de la información | Datos en reposo cifrados en Supabase (AES-256); IPs pseudonimizadas; perfiles biométricos con expiración a 90 días; sin almacenamiento de datos biométricos crudos | Cumple | Supabase encryption · src/app/api/enrollment/route.ts (expiresAt) |
| mp.sw.1 | Desarrollo de aplicaciones | TypeScript estricto, ESLint, build check en CI; CSP previene XSS; sin eval(); dependencias auditadas con npm audit | Cumple | tsconfig.json · .eslintrc · next.config.ts CSP |
| mp.info.3 | Cifrado de la información | TLS 1.3 en tránsito; AES-256 en reposo (Supabase); SHA-256 para pseudonimización de IPs; tokens de sesión con crypto.randomBytes(32) | Cumple | src/lib/auditLog.ts · src/app/api/auth/dashboard/route.ts |
El sistema aplica privacidad por diseño en el tratamiento de datos biométricos, minimizando la superficie de exposición mediante las siguientes medidas técnicas:
| Principio | Implementación técnica |
|---|---|
| Minimización de datos | Extracción biométrica 100% client-side (browser). Solo vectores derivados (estadísticas, no raw) se transmiten al servidor. |
| Pseudonimización | IPs hasheadas con SHA-256 + salt antes de almacenarse en audit log. Perfiles identificados por ID opaco (ep_*). |
| Limitación de plazo | Perfiles biométricos con expiración automática a 90 días (campo expires_at). |
| Consentimiento explícito | Modal de consentimiento RGPD Art. 9 obligatorio antes de cualquier sesión biométrica. Checkbox en /enroll. |
| Sin almacenamiento biométrico crudo | Nunca se almacenan keystroke timings individuales; solo estadísticas agregadas (media, desviación, percentiles). |
| Derecho de supresión | Endpoint DELETE /api/enrollment/:id disponible para borrado de perfil a petición del interesado. |
| Artículo AI Act | Requisito | Implementación | Estado |
|---|---|---|---|
| Art. 13 | Transparencia | Whitepaper técnico público (/whitepaper) con metodología, limitaciones y arquitectura completa | Cumple |
| Art. 14 | Supervisión humana | Términos de servicio prohíben uso como decisión automatizada sin revisión humana; dashboard con revisión manual | Cumple |
| Art. 11 | Documentación técnica | Technical whitepaper, COMPLIANCE.md, esta autodeclaración ENS | Cumple |
| Art. 9 | Gestión de riesgos | Risk register en COMPLIANCE.md; análisis de falsos positivos/negativos documentado en whitepaper §7 | Cumple |
| Art. 10 | Datos de entrenamiento | Modelo ONNX entrenado con dataset público (sintético); sin datos personales en entrenamiento | Cumple |
| Art. 15 | Robustez y ciberseguridad | 4 capas anti-adversarial (blink, rhythm_shift, inconsistency, saccade); rate limiting; CSP | Cumple |
| Control pendiente | Acción | Plazo objetivo |
|---|---|---|
| org.3 — Procedimientos completos | Documentar procedimientos operativos: backup, recuperación, cambios de configuración | Q2 2026 |
| op.exp.4 — Política mantenimiento | Establecer política formal de actualización trimestral de dependencias y parches | Q2 2026 |
| op.exp.8 — Escalación incidentes | Definir árbol de escalación: CISO → DPO → autoridad de control (AEPD) | Q2 2026 |
| Auditoría externa ENS | Solicitar entidad de certificación acreditada para validación formal nivel Básico | Q3 2026 |
| ISO 27001 — Auditoría | Contratar auditoría de certificación ISO 27001:2022 una vez estabilizado el SGSI | Q4 2026 |
Firma de la Declaración
Esta autodeclaración de conformidad con el ENS nivel Básico es emitida de forma voluntaria por Deep-Check en el marco del artículo 40 del RD 311/2022. La organización declara que las medidas de seguridad descritas están implementadas a la fecha indicada y se compromete a mantener y mejorar continuamente el nivel de conformidad alcanzado.
Responsable de Seguridad
Deep-Check
Fecha
25 de febrero de 2026
Versión
1.0