Security Overview

How data is protected, and how to report a vulnerability.

Security Overview is not yet published.

The text below is a draft awaiting legal review. It is not in force, no part of it creates any obligation or right, and nothing on this page should be relied on. Passages marked [TO BE CONFIRMED] are values that have deliberately been left blank rather than guessed.

Catomni Studio handles information about children, so these documents go to a lawyer before they take effect rather than being generated and published.

If you need answers about how your data is handled before these are published, contact your studio directly.

Draft revised: 2026-08-17

Notes for legal review

Open questions and drafting assumptions in this document. These notes are removed when the document goes into force.

  • DRAFT for review. Written to be defensible rather than reassuring: section 8 states plainly that there is no SOC 2, no ISO 27001 and no external penetration test. A security page implying audits that have not happened is a misrepresentation, and it is the kind of claim a customer will rely on in a procurement decision.
  • Every measure listed in sections 2-6 corresponds to something that exists in the code. Nothing aspirational was included. If a measure is added later, add it here then.
  • Backup frequency, retention and restoration testing are genuinely unknown to the drafter and are marked rather than guessed — an untested backup claim is a bad one to make.
  • A monitored security contact address is required for the vulnerability disclosure section to function at all. It is the single highest-value gap on this page.

1. Purpose of this page

This page describes how we protect the information in Catomni Studio, and is honest about what we have not yet done. Studios trust the platform with information about children, so we would rather tell you where the gaps are than let you infer assurances we cannot support.

2. Architecture and hosting

  • The platform runs on Cloudflare's network — application compute on Workers, the primary database on D1, and file storage on R2.
  • We do not operate our own servers or data centres, which removes a category of risk and places physical and environmental security with Cloudflare.
  • The application sits behind Cloudflare's network protections, including its web application firewall and DDoS mitigation.

3. Encryption

  • All traffic to and from the platform is encrypted in transit using TLS.
  • Data at rest is encrypted by our infrastructure providers.
  • Passwords are never stored in a readable form — only as a salted hash.
  • Application secrets are held in the platform provider's secret store, not in source control or configuration files.

4. Access control and tenancy isolation

  • Every studio's data is logically separated, and the application's data access layer scopes queries to a single studio so one tenant cannot read another's records.
  • Role-based permissions control what each of your users can see and do. You configure them; we enforce them.
  • Platform administrator accounts require multi-factor authentication.
  • A support session in which an administrator views the Service as one of your users would is time-limited to 30 minutes, cannot be extended, and is recorded in our audit log.
  • Sessions are backed by a server-side record that can be revoked, so signing out or disabling an account takes effect immediately rather than waiting for a token to expire.
  • Uploaded files, including photographs of students, are served only to users who are signed in.
  • Check-in codes are cryptographically signed and bound to a specific student and studio, so a code cannot be reused against a different record.

5. Monitoring and logging

  • Significant actions on records are written to an audit log.
  • Application errors are captured through our error monitoring provider so faults are found and fixed. See the Sub-processor List for what that involves.
  • Public forms are protected against automated abuse.

6. Resilience and backups

The database is backed up, and backups are retained and rotated on a schedule. The specifics — [TO BE CONFIRMED: backup frequency, retention period, and how often restoration is tested] — are not stated here because an untested or unverified backup claim is worse than no claim. This will be filled in with figures we can stand behind.

7. Incident response

We investigate suspected incidents, contain them, and assess what data was affected. Where a personal data breach affects a studio's data, we will notify the studio without undue delay and no later than 72 hours after becoming aware of it, with the detail set out in section 7 of the Data Processing Addendum, and we will assist the studio with its own notification obligations.

8. Certifications — what we do not have

We have not completed a SOC 2 audit. We are not certified to ISO 27001. We have not had an independent third-party penetration test. If a procurement process requires any of these, we do not currently meet it, and you should not assume otherwise from anything else on this page.

We are happy to answer a security questionnaire and to describe our practices in detail. Section 9 of the Data Processing Addendum sets out what information we will provide and the audit rights available to you in the absence of a report we can share.

9. Your part in security

  • Give each of your staff the least access they need, and review it periodically.
  • Remove access promptly when someone leaves.
  • Use a unique, strong password and do not share accounts.
  • Record only the information you actually need — the safest data is the data you never collected.
  • Treat free-text and medical notes with care, and be aware of who at your studio can see them.

10. Reporting a vulnerability

If you believe you have found a security vulnerability, please tell us at [TO BE CONFIRMED: security contact email]. Include enough detail to reproduce it. Please give us a reasonable opportunity to fix the issue before disclosing it publicly, and follow the limits in section 5 of the Acceptable Use Policy while testing.

We will acknowledge your report, keep you informed of progress, and will not pursue legal action against anyone who reports a vulnerability in good faith and within those limits. We do not currently run a paid bug bounty.