Security & data protection

Last updated: July 2026

We forecast the electricity market for the people who trade, build, and finance it, so the numbers you put into Varial are commercially sensitive by nature. We treat that data the way we'd want ours treated, and because transparency is the whole brand, here's the actual working rather than a page of adjectives.

Where your data lives

Your data is hosted in Australia, on enterprise cloud infrastructure that carries the recognised international security certifications (including ISO 27001) and has been assessed against the Australian Government's information-security framework. We don't move your data offshore for our own processing.

Encryption

In transit. Every connection is encrypted with TLS 1.2 or higher. That covers your browser talking to us and every internal hop between our own services. We force HTTPS, apply a strict HSTS policy, and refuse plain unencrypted connections at the infrastructure level, so a misconfiguration can't quietly downgrade you.

At rest. All stored data is encrypted with AES-256, including database backups and logs.

An extra layer on the sensitive stuff. On top of that disk-level encryption, the most commercially sensitive fields on your positions and valuations get a second layer of application-level encryption before they're written to the database. Each record gets its own encryption key, and those keys are themselves protected by a master key held in a dedicated, access-controlled key management service. In plain terms: a stolen copy of the raw database, on its own, can't read those fields.

Signing in, and staying signed in

  • Passwords are stored using industry-standard salted hashing and validated against length and common-password rules. We never store, log, or transmit a password in the clear.
  • Multi-factor authentication is built in. You can use an authenticator app, or a passkey or hardware security key, and back yourself up with single-use recovery codes that we store only as hashes. Teams can require MFA across all of their members.
  • Sessions are hardened with secure, HTTP-only cookies, a bounded lifetime, and a sliding idle timeout.
  • API access uses per-token authentication. Tokens are stored only as hashes, shown to you once at creation, and expire automatically.

Stopping brute-force and credential stuffing

We rate-limit the whole platform and put extra locks on the doors that matter. Sign-in, registration, and password reset are each capped, and behind that sits a durable per-account lockout that survives a cache outage and defeats attacks spread across many IP addresses. Crossing the threshold raises a security alert, not just a quiet block.

Who can see what

  • Teams and roles. Every user belongs to a team, with owner, admin, and member roles controlling who can invite, manage, and spend.
  • Invitations are single-use, token-based, and expire.
  • Support access is logged. On the rare occasion an administrator needs to act on your account to help you, every session is recorded in an audit log with who, when, and from where. That log is kept as a security record.

Secrets and keys

No credential is ever hardcoded. Every secret lives in a managed secrets vault, and in production that vault sits behind a private network boundary, so it isn't reachable from the public internet. We run a documented rotation schedule with a written procedure for each credential, and our infrastructure is managed as code so configuration stays consistent and reviewable across environments.

Hardening the application itself

  • A strict Content Security Policy controls what can run in your browser, blocks the site being framed, and disallows inline script, which shuts down whole classes of cross-site-scripting attack.
  • Standard protective security headers switch off content-type sniffing, tighten referrer behaviour, and disable browser features (camera, microphone, geolocation) the app doesn't need.
  • Our application images are scanned for known vulnerabilities on every deploy, and the running image is re-scanned on a schedule, so a vulnerability disclosed after we shipped still gets caught and triaged.

Keeping data only as long as we should

We hold data for as long as it's useful to you or the law requires, and no longer. Automated jobs purge stale invitations, old verification codes, and aged support-access logs on fixed schedules, and website telemetry (including IP addresses, which are masked by default) rolls off after 90 days.

If you ask us to delete your account, we destroy your account and profile data, with a short reversal window to catch mistakes. The one thing we keep is the financial record: billing and credit-ledger entries are held for the seven years Australian tax law requires, and your personal link to them is redacted rather than the tax record itself. Our credit ledger is append-only by design, so spend history can't be silently altered.

Watching for trouble, and what happens if something goes wrong

We monitor the running platform for errors and authentication anomalies, such as login bursts and token-leak signatures, and route serious alerts to an on-call engineer. We keep a written data-breach response procedure aligned to the Australian Notifiable Data Breaches scheme, with defined roles, an assessment process, and notification steps to the regulator and affected individuals if an eligible breach ever occurs.

What we deliberately don't collect

We don't store payment-card details, we don't collect sensitive information such as health, race, or religion, and we don't use government identifiers like tax file numbers as account keys. We identify accounts with an internal identifier instead.

Questions or something to report

We're always hardening things, so this page will keep growing. If you're weighing us up on security, or you think you've found a vulnerability, we'd genuinely like to hear from you. Please get in touch and we'll get back to you.