Trust Centre

How we handle your data, and who else touches it

A plain-English summary of where Mustr runs, which subprocessors we use, how we map against the ACSC Essential Eight at Maturity Level 1, and what happens when things go wrong.

Australian data residency

Primary production infrastructure runs in the DigitalOcean Sydney (SYD1) region. All customer data at rest — database, object storage, cache, and daily backups — is stored within Australia. A small number of supporting subprocessors (error monitoring, analytics, chat) are hosted outside Australia; see thesubprocessor list for specifics.

Essential Eight — Maturity Level 1

Self-attestation as at 2026-04-17

This is a self-assessment against the Australian Cyber Security Centre\u2019s Essential Eight mitigation strategies at Maturity Level 1 (ML1). It is not an ACSC-audited attestation and is updated as our controls mature.

Control	ML1 goal	Mustr implementation
Application control	Prevent unapproved executables, libraries, scripts, and installers from running on workstations and servers.	Production runs as minimal container images on hardened hosts with non-root users, read-only filesystems where possible, and no shell access in running containers. Development laptops run vendor-provided OS and are restricted to store-installed applications.
Patch applications	Apply security patches to operating systems and applications within two weeks of release, and within 48 hours for internet-facing services if an exploit exists.	Runtime dependencies pinned in lockfiles and rebuilt weekly. Critical CVE advisories (Snyk / GitHub Dependabot alerts) trigger out-of-band patches within 48 hours. Base container images rebuilt on upstream publish.
Configure Microsoft Office macro settings	Block Office macros from the internet; allow only digitally signed macros or macros from trusted locations.	Not applicable — Mustr does not process or execute Microsoft Office documents on the server side. Staff macOS/Windows workstations default to blocking macros from the internet per vendor defaults.
User application hardening	Disable web-browser features and plugins that are exploitable (Flash, Java, ads, auto-exec).	Staff workstations run current Chrome/Safari/Firefox only. Flash and Java browser plugins are not installed. An ad-blocker and tracker-blocker are deployed on all staff browsers.
Restrict administrative privileges	Privileged accounts used only for privileged work; regular reviews; separate from day-to-day email/browsing.	Production database administrative access is broken-glass only and requires out-of-band approval. The application connects as a restricted role that cannot disable row-level security. No persistent SSH sessions; infrastructure changes go through version-controlled scripts.
Patch operating systems	Apply OS patches within two weeks of release and within 48 hours for known exploited vulnerabilities.	Hosts run the latest LTS Ubuntu with unattended-upgrades enabled for security patches. Managed database and cache services are upgraded by the provider on their published cadence.
Multi-factor authentication	Multi-factor authentication for all users of internet-facing services, and for privileged actions on internal systems.	Staff accounts on GitHub, the hosting provider, Stripe, and domain registrar all require MFA (hardware key where available, TOTP otherwise). Customer-facing MFA on Mustr sign-in is on the roadmap; passwordless email sign-in and WebAuthn step-up are being evaluated.
Regular backups	Daily backups of important information, software, and configuration settings, retained for at least three months, tested regularly.	Managed PostgreSQL snapshots taken daily and retained 30 days. Application configuration is managed in version control. Restore-to-staging is tested at least quarterly; see the Backup & Restore section below.

Subprocessors

Everyone who touches your data

We only use subprocessors whose role we can explain in a sentence. If this list changes, we update this page before routing any customer data to the new provider.

Provider	Purpose	Data shared	Region
DigitalOcean	Primary infrastructure hosting (compute, managed PostgreSQL, object storage, managed Redis) in the Sydney region (SYD1).	All customer data and operational data, encrypted in transit and at rest.	Australia (Sydney)
Stripe	Subscription billing and payment processing.	Billing contact name, email, payment method details. Card numbers never touch Mustr servers.	Australia, with fallback processing in US
Plausible Analytics	Privacy-first website analytics (public marketing site only).	No personal data, no cookies, aggregate page views only.	EU
Sentry	Application error monitoring for the web and API.	Error stack traces, device metadata. No customer payroll, pay rate, TFN, or bank data is logged.	EU
Crisp	Customer chat on the marketing site.	Name, email, and chat message content you choose to provide.	EU
Expo (EAS)	Mobile app builds and over-the-air update delivery.	Device push tokens; no customer data.	US

Operational controls

Insurance, testing, isolation, encryption

Professional indemnity insurance

Mustr carries professional indemnity and public liability insurance (A$5M combined cover) with an Australian insurer. Certificate of currency available on request for procurement reviews.

External penetration test

A full external penetration test by an Australian security firm is conducted before general availability. Scope covers multi-tenant row-level security isolation, authentication flows, tRPC procedure authorisation, data export/import paths, and mobile API token lifecycle. A clean report is a launch gate — see the status at the bottom of this page.

Sensitive field encryption

Tax File Numbers, BSB, and bank account numbers are encrypted with AES-256-GCM before persistence. These fields are never logged, never returned in API responses unless explicitly requested by an authorised user, and never included in analytics events.

Row-level security isolation

Every tenant-scoped table enforces PostgreSQL row-level security. The application connects using a restricted role that cannot disable RLS. It is architecturally impossible for one tenant to read another tenant’s data through the application.

Backup, restore, and incident response

What happens when things go wrong

Backup and restore

Frequency: Daily managed database snapshots; 30-day retention.
Region: Snapshots stored in the Sydney region alongside primary data.
Recovery point objective (RPO): 24 hours for a full restore from snapshot; point-in-time recovery available for a rolling 7-day window.
Recovery time objective (RTO): Target of 4 hours to restore a failed primary, assuming no compounding incident.
Testing: Restore-to-staging dry run completed at least quarterly; last successful dry run logged internally.

Incident response

Security and reliability incidents are triaged within one hour during business hours (Australia/Perth) and acknowledged before end of next business day outside those hours.
Customer-impacting incidents are posted to the public status page with scope, time window, and a post-incident summary.
Eligible data breaches are notified to affected customers and to the OAIC in line with the Notifiable Data Breaches scheme — as a target, within 72 hours of confirmed impact.
To report a vulnerability, email security@mustr.com.au. We aim to acknowledge reports within one business day.

Live status

Real-time uptime, incident history, and subscribe-for-updates at status.mustr.com.au.

Open status page

Security contact

Report a vulnerability, request a security questionnaire response, or ask for our data processing agreement or certificate of currency.

Email security@mustr.com.au