Technical and security overview

Purpose. This guide gives client IT, security and procurement teams a practical overview of Cura's pilot architecture. It sits above marketing detail and below developer documentation, focusing on the controls and infrastructure relevant to technical approval.

At a glance

The short version, for anyone who needs the assurance without the detail. Every point below is expanded in the sections that follow.

• There are no passwords to steal, and nobody can sign themselves up. Everyone signs in with their own organisation's Microsoft or Google account, or a single-use email link that expires in fifteen minutes. Cura has no password field at all, so credential stuffing, password reuse and reset abuse are not possible. Access is invitation-only: a person can reach Cura only because their organisation added them.

• Each organisation's data is separated from every other's. The separation is enforced centrally at the database query layer rather than page by page, and automated tests confirm that reaching another organisation's records fails, including by changing a URL.

• Every request passes through Cloudflare before it reaches Cura. That means a Web Application Firewall, managed rulesets, the OWASP Core Rule Set, bot mitigation and rate limiting on sign-in. The application itself accepts traffic only from Cloudflare and cannot be reached directly from the open internet.

• Client data stays in the UK and EU, with named, EU-based suppliers. Traffic is encrypted in transit, and object storage and backups are encrypted at rest.

• Cura asks for as little as it can. The service needs a name, a work email address and the organisation a person belongs to. Everything else on a member's profile, including job role, seniority and any demographic detail, is optional and entirely up to the member. Cura holds no passwords, no payment or bank details, no government or national identifiers, and no HR, payroll or medical records, and it keeps no Microsoft or Google sign-in token after a member has signed in.

• Cura is built for UK GDPR and PECR. The lawful basis is stated, marketing email requires separate explicit consent, and access, rectification, erasure and objection are built into the product rather than handled by hand. Data Processing Agreement documentation is available.

• Video and sign-in links cannot usefully be forwarded. Media is delivered on signed URLs that expire, and a sign-in link works once.

1. Security overview

Cura is a multi-tenant platform: client organisations share one application while their data remains logically isolated. Security is built around three principles: no passwords to steal, strict separation between tenants, and short-lived signed access to media and links.

Authentication

Authentication is passwordless. There is no password field in the system, removing risks such as credential stuffing, password reuse and reset abuse. Users sign in through one of three routes:

• Microsoft OAuth for organisations using Microsoft 365.

• Google OAuth for organisations using Google Workspace.

• Magic Link: a single-use, time-limited sign-in link sent by email with a 15-minute expiry.

Access is invitation-only. There is no public sign-up. Users exist because their organisation has added them.

Tenant isolation

Every item of tenant-owned data is filtered automatically by organisation at the database query layer. The rule is enforced centrally and bypassing it requires an explicit, audited action. Automated tests verify that cross-tenant access fails, including attempts to reach another organisation's records by guessing IDs in URLs, and that isolation is preserved in background jobs.

Session and request security

Session cookies are HttpOnly, Secure and SameSite=Lax. All state-changing requests carry CSRF protection. Cura requests only the minimum sign-in permission from Microsoft or Google, reads the user's own name and email address once at sign-in, and retains no provider token afterwards. It does not request offline access, so no refresh token is issued and Cura has no standing means of calling a third-party API on a user's behalf.

Edge protection

All traffic passes through Cloudflare before reaching the application. Controls include a Web Application Firewall, managed rulesets, the OWASP Core Rule Set, bot mitigation and rate limiting on sign-in and magic-link endpoints. The application origin accepts traffic only from Cloudflare's network and cannot be reached directly from the open internet.

Content protection

Video is delivered using signed, short-lived URLs. Client-facing tenant areas are marked no-index so they do not appear in search engines.

Pilot scope. SAML enterprise single sign-on is not included in the pilot. Microsoft and Google OAuth cover the target organisations, with SAML planned for a later phase as demand confirms it. A formal security review covering tenant isolation, signed-URL expiry and data-rights flows is scheduled as part of the project.

2. Data: storage, encryption and compliance

Where data lives

Client data is held in the UK and EU. Compute, database and backups run in DigitalOcean's London region. Supporting media and storage services are EU-based: avatars and logos use AWS S3 in Ireland, on-demand video uses Bunny.net's EU points of presence, and live streaming and recordings use AWS in Ireland.

Encryption

Traffic is encrypted in transit: HTTPS to the edge, then TLS between the edge and the application. Object storage and database backups are encrypted at rest. Cura retains no Microsoft or Google token of any kind: a provider access token is used once, during sign-in, to read the user's own name and email address, and is then discarded. Cura does not request offline access, so no refresh token is ever issued. Its own single-use sign-in links are stored only as a SHA-256 hash, never in a form that could be replayed.

Backups and recovery

The managed database takes automated backups with point-in-time recovery, and a separate logical backup is written to independent storage to provide off-provider resilience. Backup frequency, retention periods and recovery point objectives are documented and can be shared with your security team under NDA. These specifics remain subject to change until the backup strategy is finalised.

GDPR and UK PECR

Cura processes employee data on a legitimate-interests basis for core service delivery, with separate explicit consent for marketing email. Data-subject rights are implemented as follows:

• Access: users can request a download of their data, delivered as a file by email.

• Erasure: account deletion runs an anonymisation flow. The personal record is anonymised rather than hard-deleted, preserving the historical activity log for analytics integrity while removing attribution to an individual.

• Rectification: users can edit their own profile directly.

• Objection to marketing: controlled through the user's notification preferences.

Terms and privacy-policy versions are recorded against each user to support re-acceptance when policies change, and administrative actions are logged.

Pilot scope. The right to erasure is satisfied through anonymisation. Full hard deletion, if required by a specific client, is a separate piece of work. DigitalOcean and Cloudflare provide Data Processing Agreement documentation suitable for UK GDPR.

3. Observability

Observability provides visibility into production performance, errors and uptime. Cura uses a layered approach so that no single tool becomes a single point of failure.

• Application performance monitoring captures requests, database queries, background jobs and scheduled tasks. Errors are recorded in full, routine traffic is sampled to control cost, and alerts route to the operations team.

• A self-hosted operational dashboard surfaces slow queries, queue throughput, cache performance and server resource use for the operations team.

• External uptime monitoring checks the platform from multiple regions, independently of the platform infrastructure.

• Infrastructure-level monitoring watches CPU, memory and disk, with alerts on sustained pressure.

The objective is to identify performance issues before users report them, retain enough context to diagnose errors, and detect outages from outside the system.

4. Infrastructure

Cura runs on a deliberately consolidated stack: managed services fronted by Cloudflare, with media and streaming handled by purpose-built providers. This keeps the operating model straightforward and costs predictable while supporting live events at scale.

Key points for a technical reviewer

• Data residency: compute, database and backups are in London. Media and storage services are EU-based in Ireland and other EU points of presence.

• Locked-down origin: the application accepts inbound traffic only from Cloudflare and is not directly reachable from the open internet.

• Managed database: PostgreSQL with connection pooling, automated backups and point-in-time recovery.

• Streaming at scale: live events use AWS IVS, supporting concurrent audiences in the order of tens of thousands while keeping recordings on Cura-controlled infrastructure.

• Scaling approach for the pilot: infrastructure is specified to meet forecast demand, with headroom to scale as usage grows. Demand and performance are monitored, with auto-scaling considered post-pilot if usage patterns warrant it.

• Deployment: code changes pass automated checks and human review before release, with rollback capability.

For technical approval. Your Cura contact can coordinate follow-up questions, supporting documentation and any client-specific review requirements.