1. Architecture
| Component | Platform | Purpose |
|---|---|---|
| Application and API | Cloudflare Workers | Serverless request handling. No customer-managed servers, no SSH, no operating system to patch. |
| Database | Cloudflare D1 (APAC) | Trainees, sessions, events, audit log. |
| Object storage | Cloudflare R2 (APAC) | Encrypted evidence images and generated reports. |
| Realtime coordination | Cloudflare Durable Objects | Live dashboard state fan-out. |
| Edge security | Cloudflare | TLS termination, DDoS protection, WAF, CDN. |
| Face analysis | On-device, or a dedicated GPU host | Inference. Deliberately kept off the serverless tier. |
A serverless platform removes a large class of infrastructure risk — no unpatched operating systems, no exposed management ports, no long-lived instances to drift. It concentrates the remaining risk in configuration and dependencies, which is what the rest of this policy addresses.
2. Configuration management
- Infrastructure is declared in version-controlled configuration and deployed from it. Bindings, routes, scheduled jobs and storage are code-reviewed like any other change.
- Secrets are never in the repository. They live in the platform secret store and are write-only — they cannot be read back, including by the engineer who set them.
- Development environments use separate keys and separate storage. Production keys are never used outside production.
- Security response headers are applied both at the application and at the static-asset layer, because assets are served before application code runs.
3. Dependency management
- Lockfile pinned. Builds install from a committed lockfile with integrity hashes, so a build is reproducible and a tampered package fails verification.
- Canonical registry. Lockfile entries must reference the canonical public registry over HTTPS. Local registry mirrors are permitted for speed but must not be written into the lockfile — a lockfile that only resolves on one machine is a defect, and plaintext mirror URLs are a supply-chain risk.
- Automated updates via Dependabot: minor and patch grouped weekly, majors individually so each can be tested honestly.
- Audit gate. High and critical advisories in runtime dependencies fail the build.
- Minimise the surface. Face-recognition models are self-hosted rather than fetched from a third-party CDN; the only external origins the application contacts are the web-font hosts.
- Third-party scripts are constrained by Content-Security-Policy; any script the policy does not permit simply does not execute.
4. Data residency and retention
- Storage is pinned to the Asia-Pacific region.
- Retention windows are configurable per organisation and enforced by a scheduled job. Records carry the expiry computed when they were written, so shortening a window applies to new data and cannot retroactively re-date existing evidence.
- Deletions are recorded in the audit log.
5. Availability and recovery
- The platform is globally distributed with no single customer-managed instance to fail.
- Database point-in-time recovery is provided by the platform. Restores are performed into a separate database and verified before any cutover.
- Deployments are versioned and can be rolled back to a previous version.
- Database migrations must be additive — destructive DDL fails the build — so a rollback of application code never leaves data unreadable.
- Recovery objectives: RPO 24 hours, RTO 8 hours.
6. Monitoring
- Platform observability is enabled; structured application logs cover authentication, integrations, analysis ingestion and errors.
- Post-deployment verification checks health, security headers and key endpoints.
- Logs exclude biometric data, object keys and tokens.
7. Sub-processors
Cloudflare, Inc. (hosting, storage, edge security) and — where a customer connects it — Zoom Communications, Inc. Sub-processor changes are notified to customers before they take effect. Current detail is in the Privacy Policy.
8. Review
Reviewed annually and whenever the architecture materially changes.