Teralo Security

Last Updated: 3 September 2026

This page describes Teralo's security as it is configured, not as it is intended. Where a control is not in place, it says so rather than leaving it out, because a buyer who finds one omission stops trusting the rest of the page.

Teralo holds no SOC 2, ISO 27001 or IRAP certification. ISO 27001 is the target, and no date is promised for it.

What stands in their place is set out below: the controls that are in place, the testing that is performed, and the evidence Teralo can produce on request.

Teralo runs on Cloudflare, which provides application hosting, DNS, DDoS protection, a Web Application Firewall and a global edge network.

Customer data rests in two places, and the two carry different guarantees:

• The application database is managed Postgres on Supabase, in the AWS ap-southeast-2 region in Sydney. A Supabase project's region is fixed when the project is created, so this is a hard commitment rather than a preference.
• Uploaded files, meaning documents, drawings, photos, mail and meeting attachments and signed PDFs, are held in Cloudflare R2 in a bucket carrying Cloudflare's Oceania location hint. Cloudflare documents a location hint as a best effort rather than a guarantee, and publishes no Australian jurisdiction that would make it one. Teralo therefore does not describe file storage as contractually resident in Australia.

Static assets and cached responses are served from Cloudflare's global edge network.

Connections to Teralo use HTTPS with Transport Layer Security (TLS) 1.2 or above.

Data at rest is encrypted by the platforms holding it. Supabase encrypts all customer data at rest with AES-256. Cloudflare R2 encrypts every object and its metadata at rest with AES-256 in GCM mode, automatically and with keys managed by Cloudflare.

• Sign-in is with a work account through Google, Microsoft or Apple, or with an email address and password.
• Multi-factor authentication is available to every user, using time-based one-time passcodes (TOTP) with single-use backup codes. It is mandatory for Teralo staff accounts holding administrative access.
• Organisation-wide MFA enforcement is not available yet. A customer cannot currently require MFA of all its own users from within Teralo.
• SAML single sign-on and SCIM deprovisioning are not supported. Both are on the roadmap and neither has shipped.
• Role-based permissions assign each user a role in an organisation and in each project. Access to a record follows from those roles, and is enforced on the server rather than by hiding controls in the interface.

• Automated daily backups of the application database, retained for seven days.
• The recovery point objective this delivers is up to 24 hours.
• Point-in-time recovery is not currently enabled.

Teralo does not publish a recovery time objective, because no documented restore drill has been performed. Both the objective and the date of the drill will be published here once one has been run.

Systems are continuously monitored for availability and for anomalous behaviour. Teralo targets 99.99% availability, reported on a live status page linked from the site footer.

Incidents follow a documented process of investigation, containment, remediation and post-incident analysis. Where an incident affects personal information, Teralo notifies affected customers and, where the scheme requires it, the Office of the Australian Information Commissioner under the Notifiable Data Breaches scheme.

Teralo runs automated penetration testing using the open-source Shannon agent (Keygraph). Runs cover authentication, authorisation, injection, cross-site scripting and server-side request forgery, and each one produces a written security assessment report. Testing is periodic rather than on a fixed schedule, and the most recent completed run was in July 2026.

Teralo does not engage a third-party penetration testing firm, so there is no independent attestation letter to share. The assessment report from the most recent run can be provided to a customer under a non-disclosure agreement.

Software updates introduce new features, enhancements and performance improvements, deployed to all customers at once. Releases are tested in development and staging environments before deployment. Major releases include release notes.

Teralo's AI features run on Google Gemini. Use of AI is optional, and a project without the AI permission has no AI features at all.

AI prompts and responses are sent to the Google Gemini Developer API, which under its paid-tier terms does not use them to train or improve Google products, and are not sent to Teralo's product analytics provider.

What that means in practice:

• Prompt and response content is not copied to an analytics service. Teralo's product analytics receives measurements of each call and nothing else: the model, token counts, cost, latency, and whether it succeeded. It receives none of what you asked, none of what the assistant answered, and none of the project records the assistant read in order to answer.
• Your conversation is stored in Teralo like any other record, in the Sydney database and under the same access controls as the rest of your project data, and is deleted when you delete it or the project is deleted.
• They are not used to train models, by Teralo or by Google. Google's paid-tier API terms state that Google does not use prompts or responses to improve its products, and log them only for a limited period to detect abuse.
• There is no regional processing guarantee. Teralo uses the Gemini Developer API, which does not offer one. Prompts may be processed on Google infrastructure outside Australia.

The full position, including what the assistant is given access to, is in the AI Product Terms and the Privacy Policy.

Every third party that receives data on Teralo's behalf is named, with its purpose and processing location, on the sub-processor page.

For questions about security, or to request a penetration testing report, please contact us at support@teralo.co.