Frequently asked questions

What is Cura?

Cura is an invitation-only cloud platform that delivers short learning experiences, practical missions, reminders and progress support through a client-specific workspace.

Who contracts with the client?

Mobile Feel Good Company Limited, company registration number 03625117, registered office 34 Woodland Rise, London, N10 3UG.

Where is the service hosted?

Core compute, managed PostgreSQL and backups are in DigitalOcean's London region. Supporting media and storage services are EU-based, including AWS Ireland and Bunny.net EU delivery.

Is the service multi-tenant?

Yes. Client organisations share the application while tenant-owned data is logically isolated by organisation.

How is tenant separation enforced?

Organisation filtering is enforced centrally at the database query layer. Automated tests check cross-tenant access, guessed record identifiers and background jobs.

Does Cura store passwords?

No. Cura uses Microsoft OAuth, Google OAuth or a single-use Magic Link with a 15-minute expiry.

Does Cura support SAML SSO?

SAML is not included in the pilot. Microsoft and Google OAuth are available, with Magic Link as an alternative.

Is access publicly available?

No. Access is invitation-only; there is no public sign-up.

How are sessions protected?

Session cookies are HttpOnly, Secure and SameSite=Lax. State-changing requests include CSRF protection.

Is data encrypted in transit?

Yes. Traffic uses HTTPS to the edge and TLS between the edge and application.

Is data encrypted at rest?

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.

How is the application protected from internet threats?

Traffic passes through Cloudflare controls including a WAF, managed rulesets, the OWASP Core Rule Set, bot mitigation and rate limiting on sign-in and Magic Link endpoints.

Can the origin server be reached directly?

The application origin is configured to accept traffic only from Cloudflare's network and is not directly reachable from the open internet.

How is media access protected?

On-demand video uses signed, short-lived URLs. Client tenant areas are marked no-index.

Are administrative activities logged?

Yes. Administrative actions are logged. Exact events and retention can be confirmed for your response.

Do you perform penetration testing?

A formal security review covering tenant isolation, signed-URL expiry and data-rights flows is scheduled. Scope, provider, timing and a client-safe findings summary can be confirmed with your Cura contact.

Who owns client data?

The service agreement states that the client retains ownership of Customer Data and grants Cura a limited licence to process it to provide the service.

Does Cura sell client data?

No. The service agreement states that Cura will not sell Customer Data to third parties.

What are the parties' privacy roles?

The client acts as controller and Cura acts as processor for client-directed service data. Any independent-controller activity is identified in the executed DPA.

How are access requests handled?

Users can request a copy of their data, prepared as a file and delivered by email. The identity-verification and delivery process is confirmed in the DPA workflow.

How is erasure handled?

The current flow anonymises the personal record so historical activity is no longer attributable to an individual. Full hard deletion is separate work if required by a client.

What happens at termination?

The agreement provides a 30-day period in which Customer Data is available for export, after which it may be securely deleted.

Do you use subprocessors?

Yes. The current architecture uses DigitalOcean, Cloudflare, AWS and Bunny.net. The full subprocessor register, with legal entities, locations and safeguards, is provided with the DPA.

How will clients be notified of a personal-data breach?

The executed DPA requires Cura, as processor, to notify the client without undue delay after becoming aware. Named contacts, content and target timings are agreed with your team.

How is the service monitored?

Cura uses application performance monitoring, an operational dashboard, independent multi-region uptime checks, and infrastructure monitoring for CPU, memory and disk.

How are alerts handled?

Application alerts route to the operations team. On-call coverage, escalation times and named owners are confirmed at contract.

How is data backed up?

The managed database takes automated backups with point-in-time recovery, and a separate logical backup is retained in independent storage. Frequency and retention periods can be shared with your security team under NDA.

What is the recovery point objective?

Recovery point objectives are documented and can be shared with your security team under NDA. Treat them as a draft target until they are agreed contractually.

What is the recovery time objective?

A recovery time target is not yet stated and will be confirmed by scenario before it is offered as a commitment.

How are changes released?

Changes pass automated checks and human review before release, with rollback capability.

Do you have an incident-response plan?

An incident-response and continuity overview exists. Role-holders, out-of-hours coverage, exercises and notification commitments are agreed as part of onboarding.

What support is provided?

The service agreement provides reasonable technical support during normal business hours. The client-specific route, hours and targets are set in the Order Form or pilot plan.

Do you guarantee uninterrupted service?

The current agreement does not guarantee uninterrupted or error-free operation. Any SLA or service-credit terms are agreed separately.