ISO/IEC 27001:2022 — Annex A Controls · Deep-Check Biometric Identity Verification Platform
Pre-Certification Statement of Applicability
This document constitutes a voluntary Statement of Applicability (SoA) for ISO/IEC 27001:2022. Deep-Check has not yet undergone formal certification by an accredited certification body. This SoA documents the current implementation status of Annex A controls and serves as preparation for formal certification (target: Q4 2026). All implemented controls are technically verifiable in the codebase and infrastructure.
| Organization | Deep-Check |
| System in scope | Web-based biometric identity verification and document forensics SaaS platform |
| Standard version | ISO/IEC 27001:2022 (Annex A, 93 controls across 4 themes) |
| SoA version | 1.0 |
| SoA date | 25 February 2026 |
| Scope boundary | Application layer (Next.js), API layer, database (Supabase EU), ML inference (Vercel) |
| Out of scope | Physical offices (cloud-only), end-user devices (candidate browsers), third-party identity providers |
| Risk appetite | Low (biometric special category data warrants conservative risk posture) |
| Target certification | Q4 2026, pending budget allocation for accredited audit body |
86% of applicable controls are implemented or in progress. Planned controls target Q2–Q3 2026 (MFA, formal incident procedures, ISMS audit cycle, staff training).
Controls marked N/A are not applicable due to cloud-only architecture (no physical premises, no end-user hardware managed). All N/A justifications are documented below.
| Ref | Control | Rationale for inclusion/exclusion | Implementation summary | Status |
|---|---|---|---|---|
| A.5.1 | Policies for information security | Required to establish security governance | Security policy published at /security; Privacy Policy at /privacy; Terms at /terms. COMPLIANCE.md contains internal ISMS policy. | Implemented |
| A.5.2 | Information security roles and responsibilities | Required for accountability | Roles defined: Data Controller (Deep-Check), DPO (pending formal appointment), Security Lead. Documented in COMPLIANCE.md. | Planned |
| A.5.10 | Acceptable use of information and other assets | Required to prevent misuse of biometric data | Terms of Service §2 defines acceptable/prohibited uses; automated decision-making without human review explicitly prohibited. | Implemented |
| A.5.12 | Classification of information | Biometric data = special category, requires classification | Data classification documented: biometric profiles (Confidential), audit logs (Internal), public content (Public). In COMPLIANCE.md §2. | Implemented |
| A.5.15 | Access control | Required to protect biometric data and admin functions | Dashboard access: httpOnly session cookie, timingSafeEqual auth; Supabase: RLS policies per table; API: rate limiting in middleware; env vars: Vercel secrets. | Implemented |
| A.5.17 | Authentication information | Secure credential management for admin access | Admin session tokens: 32-byte crypto.randomBytes(); stored hashed in dc_admin_sessions; 8h expiry; timingSafeEqual comparison prevents timing attacks. | Implemented |
| A.5.23 | Information security for use of cloud services | Supabase and Vercel are cloud service providers | Supabase: EU region, ISO 27001 certified, SOC 2. Vercel: SOC 2 Type II. Sub-processor list in Privacy Policy §7. | Implemented |
| A.5.24 | Information security incident management planning | Required for breach response | Responsible disclosure policy published at /security §4. Vercel provides incident alerting. Formal ISMS incident procedure: planned. | Planned |
| A.5.26 | Response to information security incidents | GDPR Art. 33 requires 72h breach notification | Incident response contact (security@deep-check.app) published in security.txt. 72h AEPD notification process documented in COMPLIANCE.md. | Planned |
| A.5.29 | Information security during disruption | Service continuity for biometric verification | Vercel provides global CDN with automatic failover. Supabase provides daily automated backups. Formal BCP: planned. | Planned |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | GDPR, EU AI Act, ENS compliance required | GDPR Art. 9 consent gates implemented; ENS Básico autodeclaración published at /ens; EU AI Act Art. 13/14 implemented; legal register in COMPLIANCE.md. | Implemented |
| A.5.32 | Intellectual property rights | OSS license compliance | ONNX model: Apache 2.0 compatible; all npm dependencies: MIT/Apache/ISC; no GPL-licensed dependencies in production build. | Implemented |
| A.5.33 | Protection of records | Audit log integrity required by ENS op.exp.7 | Audit logs in dc_audit_logs (Supabase): append-only via service_role; RLS blocks user modification; pseudonymized IPs. | Implemented |
| A.5.36 | Compliance with policies and standards | Required for ISMS operation | This SoA document + ENS autodeclaración constitute compliance documentation. Internal audit cycle: planned (biannual). | Planned |
| A.6.1 | Screening | Background checks for personnel with access to biometric data | Currently sole developer with full access. Formal screening process required upon team expansion. | N/A |
| A.6.3 | Information security awareness, education and training | Required for secure operations | Security training planned for Q3 2026 upon team growth. Current team: developer with security background. | Planned |
| A.6.8 | Information security event reporting | Required to detect and report security events | Security events auto-logged to dc_audit_logs; error 5xx alerts via Vercel; responsible disclosure email in security.txt. | Implemented |
| A.7.1 | Physical security perimeters | No physical infrastructure — cloud-only | N/A: All infrastructure is cloud-hosted (Vercel, Supabase). Physical security delegated to cloud providers (ISO 27001 certified). | N/A |
| A.8.1 | User endpoint devices | Candidate devices process biometric data locally | All biometric extraction runs client-side in sandboxed browser environment. No data stored on candidate devices beyond localStorage consent flag. | Implemented |
| A.8.2 | Privileged access rights | Admin access to Supabase and dashboard requires protection | Supabase service role key stored in Vercel encrypted environment; not exposed to client; dashboard requires session token. | Implemented |
| A.8.5 | Secure authentication | Multi-factor authentication for admin access | Admin auth: password + session token (2-factor equivalent). MFA via TOTP: planned for Q2 2026. | Planned |
| A.8.6 | Capacity management | Prevent denial-of-service affecting availability | Rate limiting: 20 req/min per IP on /api/ml-score (CPU-intensive); 100 req/min default. Vercel auto-scales. Supabase connection pooling. | Implemented |
| A.8.7 | Protection against malware | Required for application security | npm audit on CI/CD pipeline; no eval(); strict CSP blocks inline scripts; TypeScript strict mode prevents common vulnerabilities. | Implemented |
| A.8.8 | Management of technical vulnerabilities | Required to maintain security posture | npm audit run on each deployment; Dependabot alerts enabled on GitHub; responsible disclosure policy at /security §4. | Implemented |
| A.8.9 | Configuration management | Secure configuration baseline | Infrastructure as code: next.config.ts (security headers), Supabase migrations version-controlled; environment variables in Vercel (not in code). | Implemented |
| A.8.11 | Data masking | Required for pseudonymisation of biometric data | IP addresses hashed with SHA-256+salt before storage; biometric profiles use opaque IDs (ep_*); no PII in URLs; email only stored as identifier. | Implemented |
| A.8.12 | Data leakage prevention | Prevent exfiltration of biometric profiles | CSP blocks data exfiltration to unauthorized domains; Supabase RLS limits data access by role; API responses never include raw keystroke timings. | Implemented |
| A.8.15 | Logging | Required for security monitoring and forensics | Structured audit log (dc_audit_logs): all API calls, auth events, enrollment, assessment saves. Middleware logs all requests with X-Request-ID. IP pseudonymized. | Implemented |
| A.8.16 | Monitoring activities | Required for anomaly and intrusion detection | Rate limiting detects abuse patterns; Vercel Analytics monitors latency/errors; audit log enables retrospective analysis; error 4xx/5xx tracked. | Implemented |
| A.8.20 | Networks security | Required to secure API communications | HTTPS enforced (HSTS max-age=31536000, preload); TLS 1.3 minimum; no HTTP fallback. Supabase traffic over TLS. Vercel edge network. | Implemented |
| A.8.22 | Segregation of networks | Isolation of production database | Supabase service role key only on server-side (Vercel env); public anon key has RLS restrictions; no direct database access from client. | Implemented |
| A.8.24 | Use of cryptography | Required for data protection | TLS 1.3 in transit; AES-256 at rest (Supabase); SHA-256 for IP hashing; crypto.randomBytes(32) for session tokens; crypto.timingSafeEqual for auth. | Implemented |
| A.8.25 | Secure development life cycle | Required for application security | TypeScript strict; ESLint security rules; PR reviews (planned); penetration testing (planned Q3 2026); OWASP Top 10 checklist applied. | Implemented |
| A.8.26 | Application security requirements | Security by design for the verification platform | Security requirements documented: anti-spoofing (4 layers), rate limiting, consent gates, audit logging, CSP, HSTS. See /whitepaper and /security. | Implemented |
| A.8.28 | Secure coding | Prevent common vulnerabilities in application code | TypeScript strict null checks; no eval(); parameterized Supabase queries (ORM prevents SQLi); Content-Security-Policy; no secrets in code (env vars). | Implemented |
| A.8.32 | Change management | Control changes to the production system | All changes via git commits on GitHub; Vercel auto-deploys from main branch with build checks; TypeScript compilation required before deploy. | Implemented |
| Risk | Likelihood | Impact | Treatment | Controls |
|---|---|---|---|---|
| Biometric spoofing (replay/synthetic) | Medium | High | Mitigate | A.8.26, A.8.28 — 4 anti-adversarial layers (blink, rhythm_shift, inconsistency, saccade) |
| API abuse / DDoS on ML endpoint | High | Medium | Mitigate | A.8.6 — Rate limiting 20 req/min per IP; Vercel auto-scale |
| Biometric data exfiltration | Low | Critical | Mitigate | A.5.33, A.8.11, A.8.12 — RLS, CSP, pseudonymisation, no raw data stored |
| Admin account compromise | Low | High | Mitigate | A.5.17, A.8.5 — 32-byte random tokens, timingSafeEqual, 8h session expiry |
| Supply chain attack (npm) | Medium | High | Mitigate | A.8.7, A.8.8 — npm audit, Dependabot, minimal dependency surface |
| GDPR Art. 9 breach notification failure | Low | High | Mitigate | A.5.26 — 72h notification procedure documented; DPO appointment planned |
| EU AI Act high-risk classification | Medium | High | Mitigate | A.5.31 — Art. 13/14 implemented; technical documentation published |
| Vendor lock-in / provider outage (Supabase) | Low | Medium | Accept | Supabase: 99.9% SLA; Vercel fallback. Full migration feasible: PostgreSQL-compatible. |
| Milestone | Description | Target | Status |
|---|---|---|---|
| ISMS documentation complete | SoA, Risk Register, Asset Inventory, Policies — all documented | Q1 2026 | Done |
| Technical controls implemented | All A.8 technological controls: rate limiting, audit log, crypto, CSP, HSTS | Q1 2026 | Done |
| ENS Básico autodeclaración | Voluntary self-declaration of ENS Básico conformity (RD 311/2022) | Q1 2026 | Done |
| MFA for admin dashboard | TOTP-based second factor for /dashboard access | Q2 2026 | Planned |
| Formal incident procedure | Written IRP with escalation tree, GDPR 72h notification workflow | Q2 2026 | Planned |
| Internal ISMS audit | First internal audit of ISMS controls against ISO 27001:2022 | Q3 2026 | Planned |
| Penetration test | External pentest of API and biometric pipeline | Q3 2026 | Planned |
| ISO 27001:2022 Stage 1 audit | Documentation review by accredited certification body | Q4 2026 | Planned |
| ISO 27001:2022 Stage 2 audit | On-site certification audit — target certification | Q1 2027 | Planned |