Security

Technical and Organisational Security Measures

This page describes the security measures DenBrain Ltd implements for DenBrain. It supports the Data Processing Agreement (/dpa) and is more detailed than the summary in the Privacy Notice. It describes controls in place at the date below; it is not a certification or an assurance that any system is free of vulnerabilities, and DenBrain holds no security certifications (for example ISO 27001, SOC 2, Cyber Essentials or PCI DSS). It has not been the subject of an independent penetration test. Security questions: hello@denbrain.co.uk. Last updated: 28 October 2026.

A. Infrastructure and hosting

DenBrain runs as a modular application on a single virtual private server from Hostinger.

• The server runs a long-term-support release of Ubuntu Linux.
• The application, background worker, database and web server run as separate containers on a private container network. Only the web server publishes ports to the internet (HTTPS and HTTP-to-HTTPS redirect); the application, worker and database are not published.
• Administrative access to the server is by SSH key only; password and root login are disabled.
• Public traffic is served over HTTPS with certificates issued and renewed automatically, and HTTP Strict Transport Security is sent.
• Container logs are size-capped and rotated automatically (five files of 10 MB per service).

B. Database and tenant isolation

Customer data is held in PostgreSQL.

• Each practice's data is separated from other practices' data at database level using PostgreSQL row-level security, which is forced on every tenant table so it applies even to the table owner.
• The running application and the background worker connect with restricted database roles that are not superusers and cannot bypass row-level security. A separate privileged role is used only for schema migrations, not by the running service.
• The background worker applies its elevated job-claiming privileges per transaction rather than for the whole connection.
• Patient photographs are never stored in the database; only references to private object storage are.
• The database is not reachable from outside the private container network.

C. Authentication and authorisation

• Passwords are stored only as salted hashes using scrypt; plain-text passwords are never stored.
• Sessions use a cookie that is HttpOnly, limited to 12 hours, and a separate anti-forgery (CSRF) token protects state-changing requests.
• Rate limits apply to sign-in and other authentication endpoints and to the public widget endpoints.
• Access decisions are enforced on the server, not in the browser. Users are scoped to their own organisation and practice, and role checks apply (for example, only owners and practice managers can manage billing).

D. Widget and embed security

• Each practice registers the website origins allowed to embed its widgets; embedding from other origins is refused by the server.
• The embedding website's identity is verified from the browser's Referer when the embedded page first loads and is then carried by a short-lived (60-second), signed authorisation token that cannot be reused for a different purpose.
• Public widget pages are the only pages that can be framed by other websites; all other pages refuse framing.
• A per-request, nonce-based Content Security Policy restricts which scripts can run. Photo upload pages additionally allow connections only to the configured storage origin.
• Patient-facing pages set no cookies and load no third-party scripts or analytics.

E. Object storage

• Patient photos and generated previews are stored in private Cloudflare R2 storage, accessed only through short-lived signed links created by the server.
• Browser uploads to storage go directly to the storage origin using signed upload links; the storage bucket allows cross-origin uploads only from DenBrain's own website origin.
• Database backups are held in a separate bucket with separate credentials.

F. Photo handling and retention

• Uploaded photos are validated for file type, size and dimensions before use.
• Patient photographs are used for a Smile Preview only after the patient's explicit consent, and the patient separately acknowledges that the result is illustrative only.
• Original uploaded photos are deleted immediately after successful processing where possible. Failed or abandoned uploads are removed by an automated cleanup process that runs hourly and deletes originals more than 24 hours old. Generated Smile Preview images (the preview and the 'before' image shown beside it) are temporary: they are available for 24 hours and are then deleted automatically, unless the practice deliberately saves them from its DenBrain dashboard. Images a practice saves are held as that practice's own record, for as long as the practice keeps them, outside this temporary window. An automated hourly job enforces this, and the service refuses to show an expired image from the moment it expires.
• Photo contents are not written to application logs, and error handling is designed so that provider errors are discarded rather than logged in a way that could include a photo.
• A watermark can be applied to generated previews.

G. Image generation provider (fal.ai)

• The image-generation provider is accessed through an abstraction layer, so it can be replaced without changing the rest of the application.
• The patient's photo is sent to fal.ai only after consent, over HTTPS, using a server-side credential that is never exposed to browsers.
• DenBrain sends fal.ai's documented instruction not to store request payloads with every request and receives the generated image directly, rather than as a provider-hosted link.
• Each request is submitted at most once; failed generations are not automatically retried, which also avoids sending the same photo repeatedly.
• Results from the provider are validated before use, and any provider download is restricted to an allow-list of the provider's own hosts and does not follow redirects.
• DenBrain does not use patient photos to train AI models.

H. Application and API security

• Input to API endpoints is validated on the server.
• Security headers are set on all responses, including a Content Security Policy, frame restrictions and HTTP Strict Transport Security.
• Internal operational endpoints reject any request that does not present a server-side secret.

I. Payments (Stripe)

• Card details are entered with, and held by, Stripe; DenBrain does not store full card numbers.
• Stripe webhook events are verified against Stripe's signature before they are acted on, and processing is idempotent.
• Billing management is restricted to owners and practice managers.

J. Email

• Service emails (account, password-reset and billing messages) are sent through an authenticated SMTP connection to Hostinger's email service.
• Password-reset links are single-use and expire.
• DenBrain does not send marketing email to patients.

K. Backup and disaster recovery

• The database is backed up automatically every day.
• Each backup is encrypted (AES-256) before it leaves the server, and the encryption key is held on the server separately from the backups, readable only by the system administrator account.
• Encrypted backups are stored off the server in a separate Cloudflare R2 bucket using credentials that are separate from those used for patient photos.
• Backups older than 35 days are deleted automatically, with a safeguard that always keeps a minimum number of recent backups so that a failed run cannot delete the only copies.
• A freshness check alerts DenBrain operators by email if a backup is missing or stale, and if a backup or pruning run fails.
• Restore tests are a periodic operational task.

L. Deployment and supply chain

• Secrets are held in a restricted file on the server and are not stored in the source repository.
• Releases are built into container images from a tagged source tree and deployed with a script that checks file modes and publication gates before deployment.
• A rollback copy of the previous release is kept when deploying.
• Application dependencies are pinned by lock file.

M. Testing and assurance

• DenBrain has an automated test suite covering, among other things, tenant isolation under row-level security, widget embed authorisation, upload state checks, billing role checks and entitlement windows, backup retention, and security headers.
• Typechecking, linting and a production build run before each release.
• DenBrain has carried out internal security reviews of the application. It has not commissioned an independent penetration test.

N. Incident and breach response

• Backup status is monitored, and operators are alerted by email if a backup is missing, stale or fails.
• Suspected incidents are assessed to determine whether personal data is affected, and containment, investigation and remediation follow.
• Where a personal data breach affects data DenBrain processes for a practice, DenBrain notifies the practice without undue delay and provides the information the practice needs to meet its own obligations (DPA clause 10). The practice, as controller, decides whether to notify the ICO and individuals; DenBrain does so for data where it is itself the controller where the law requires.

O. Organisational measures

• Access to the production server is limited to DenBrain's administrator and uses SSH key authentication.
• Subprocessors are listed at /subprocessors and are bound by their own data protection terms.