Security

Docket runs on dedicated infrastructure in an Australian Equinix data centre. Your books data, backups, and logs all live in Australia. We don't ship data offshore as part of normal operations.

A handful of sub-processors (Stripe, GoCardless, plus a couple of TID-owned services for SMS and email) operate partly outside Australia. We send them only the minimum data needed for their function — they don't get a mirror of your books. The full list is in our Privacy policy.

In transit: TLS 1.2+ on every public surface. HSTS on the marketing and app domains. We don't accept plaintext HTTP.

At rest: Disk-level encryption on the database and object storage. Backups are encrypted at the storage layer. Database connections inside our infrastructure run over TLS.

Docket is multi-tenant. Every tenant-scoped table in our Postgres database has FORCE ROW LEVEL SECURITY enabled with an org-id policy. Application code sets the active org per database transaction; queries that forget to set it return zero rows by design. This means a bug in the application layer can't accidentally leak one customer's data to another.

Passkeys (WebAuthn) are the preferred login method. Magic-link via email or SMS is available as a fallback. We don't store user passwords because we don't use them.

API access uses opaque bearer tokens scoped per app. Token grants are tied to a user + scopes; revocation is immediate.

Card details never touch our servers. The public pay page mounts Stripe Elements, which sends card data directly to Stripe; we receive a token back, plus the amount, status, and last-four for display. We're not in the cardholder-data environment, so PCI scope on the Docket side is limited.

Bank-feed connections are handled by Basiq under the CDR. You authorise the connection on your bank's side and on the Basiq consent page; Docket never sees your banking credentials. You can revoke the connection at any time from settings, and Basiq honours that revocation upstream.

We back up the primary database continuously and snapshot daily. Backups stay onshore. We test restore procedures regularly. Specific RPO / RTO numbers are being formalised as part of our DR plan.

Server logs (request paths, status codes, timestamps, request ids) are retained for a short rolling window for incident response. We don't log request bodies or response bodies as a matter of routine; ad-hoc tracing of a specific incident may capture more but is purged when the incident closes.

We're working toward DSP (Digital Service Provider) accreditation with the ATO so we can offer direct BAS lodgement. SOC 2 / ISO 27001 are on the roadmap; we're not yet certified.

If you find a security issue, please email hello@theitdept.au. We'll acknowledge within two business days and aim to ship a fix within a window proportionate to severity. We commit to:

• Not pursuing legal action against good-faith research.
• Crediting researchers in the disclosure notes if they want to be named.
• Not using the issue to claim you violated our terms while you reported it.

Please don't:

• Probe production with destructive payloads.
• Access or modify other customers' data.
• Run high-volume scans against the service.

We don't run a paid bug-bounty program yet, but we do say thank you, and we mean it.

Listed in our Privacy policy. If we add or change a sub-processor in a way that materially affects how your data is handled, we'll email you before it takes effect.

The IT Dept Pty Ltd · ABN 12 665 405 505 · hello@theitdept.au