How we look after your data.

Where your data lives

PlanHouse runs on a Vultr instance in their Australian (Sydney) region. File storage and encrypted backups sit in Cloudflare R2's Oceania jurisdiction. In normal operation your firm's data stays within Australia or New Zealand.

The exception is AI inference: requests we send to our AI provider (Anthropic) are processed outside the region. We disclose this — and every other vendor that touches firm data — on the sub-processors page.

Tenant isolation

Every database query is scoped to your firm at the data-access layer, not just hidden in the UI. There is no path through the application that reads another firm's records. This is enforced in server code on every request — not a UI affordance you could bypass with a different URL.

Encryption

PlanHouse uses four layers of encryption, each protecting a different failure mode.

• In transit. All connections to the application are served over HTTPS, terminated at our managed reverse proxy (Caddy) with automatically-renewing Let's Encrypt certificates. Internal traffic between the application and the database runs on the same host over a loopback interface; the database is not reachable from the public internet.
• At rest, infrastructure layer. The Vultr volumes that hold the database and the application disk are encrypted at rest at the storage layer. File storage in Cloudflare R2 is AES-256-encrypted at the object layer.
• At rest, application layer. The highest-sensitivity fields — currently your MFA seeds and recovery codes, and extending to identifiers like tax file numbers as those features ship — are additionally encrypted with AES-256-GCM before they touch the database. The encryption key is held by us, kept on the server outside the database, and never travels with the data.
• Backups. Database dumps are encrypted at the application layer with a separately-held key before they leave the server, then written to a separate R2 bucket with object-lock retention. Cloudflare cannot read the backup contents even with full account access.

Sign-in and multi-factor authentication

Sign-in is email + password. Two-factor authentication (TOTP — a six-digit code from an authenticator app) is available to every user and can be enforced firm-wide by your firm admin. Platform administrators must enrol. Each enrolled user gets ten single-use recovery codes; lost-device recovery goes through your firm admin.

Passwords are stored as bcrypt hashes, must be at least 12 characters, and are checked against the Have I Been Pwned breach corpus on every change — passwords that have appeared in a public breach are rejected. Following NIST SP 800-63B guidance we do not impose composition rules (forced mixed case, digits or specials); a strength meter is shown alongside the input as guidance.

Failed sign-in attempts are rate-limited per IP, and a neutral-response forgot-password flow protects against email enumeration. User sessions idle out after 60 minutes of inactivity and end absolutely after 12 hours, after which sign-in is required again. Sessions can be revoked immediately by an admin — suspending an account, resetting a password or changing a role takes effect on the next request, not after the session expires.

Roles and access control

Roles inside a firm (firm admin, adviser, paraplanner, client service, read-only) and client-level sharing (which advisers can see which clients) are checked server-side on every endpoint. Platform administration is a separate account scope from any firm login. When a platform administrator opens a firm for support, the impersonation is logged and a banner is visible across the session; every action taken during impersonation records both identities in the audit trail.

AI and your data

AI features in PlanHouse are grounded in the single client's record being worked on — we do not blend information across clients or firms. Requests are made to Anthropic's Claude API under their commercial terms: Anthropic does not use API inputs or outputs to train or improve their models. Anthropic may retain request and response data for a short period for safety and abuse monitoring as described in their API terms.

Every AI output is treated as a draft for adviser review — a strategy suggestion, a drafted SOA section, a meeting note. The adviser is the licensed party and remains responsible for the advice. We do not finalise client-facing documents without explicit adviser approval.

User-entered content (meeting notes, knowledge-base articles) is treated as untrusted when it feeds into AI context, and the adviser-in-the-loop review remains the backstop. AI use is rate-limited per user and per firm so a misbehaving integration or runaway loop cannot drain credits or generate at unbounded cost.

Backups and recovery

The production database is dumped nightly. Dumps are encrypted locally with a key that is held separately from the database, is not stored in source control, and is not accessible from the application runtime, then uploaded to a separate R2 bucket whose API token is write-only and held only by the backup process. Files in object storage are mirrored to the same backup bucket. Backups carry 30-day object-lock retention so an attacker who reaches the application cannot rewrite backup history.

The restore procedure is documented and rehearsed end-to-end (database decrypt, restore, encrypted-field round-trip, file-asset spot check) before broader beta opens, and is re-rehearsed periodically.

Audit trail

Sign-ins, record changes, document approvals and issues, file exports, AI generations, MFA enrolment and reset, platform impersonation, and integration connect/disconnect events are written to an append-only audit log. Firm administrators can see their own firm's log and download it as CSV; platform administrators can see the cross-firm log for support and incident response.

A regulator-ready compliance bundle can be exported per client — a ZIP containing issued document PDFs, immutable fact-find snapshots, file notes, the compliance register and the activity timeline, with per-file SHA-256 in the manifest.

File uploads

Files uploaded by advisers are scanned for malware on receipt (synchronous ClamAV scan; failed scans reject the upload). File types are validated by magic-byte detection against a strict allowlist — PDFs, common images, Office documents, CSV and plain text. HTML, SVG, executables and archives are blocked. Per-file size is capped, filenames are sanitised, and storage keys are generated server-side so a malicious filename cannot escape the storage path.

Downloads are served via short-lived signed URLs with Content-Disposition: attachment and X-Content-Type-Options: nosniff set on every response. Files are never rendered inline in the browser. Anything found infected is quarantined for evidence rather than deleted, and is never available to download.

Operational hardening

• Host. UFW firewall (only HTTP/HTTPS/SSH inbound), fail2ban for SSH brute-force protection, key-only SSH (no password authentication), unattended security updates.
• Browser hardening. HSTS, a strict Content-Security-Policy, frame-ancestors deny, X-Content-Type-Options nosniff, a strict-origin-when-cross-origin referrer policy, and a locked-down Permissions-Policy (camera, microphone, geolocation, payment) on every response. CSP violation reports are captured to the audit log for review.
• Secrets. Long-lived secrets (database credentials, backup passphrase, field-encryption key) are stored on the host outside the application directory with restricted permissions, mirrored in a password manager, and held offline. They are not in source control. Quarterly key-rotation procedure is documented.
• Public sign-up. Closed during private beta — new firms are provisioned by us after an introductory call.

Sub-processors

A short, current list of vendors that process firm data on our behalf is published at planhouse.ai/subprocessors. We notify active firms before adding or changing a sub-processor that handles personal information.

Reporting a vulnerability

If you believe you've found a security issue in the PlanHouse application or this marketing site, please email [email protected] with a description and steps to reproduce. We aim to acknowledge reports within two business days. Please do not test against any firm's production data.

A note on framing

PlanHouse is a productivity tool for licensed financial advisers. We are not an Australian Financial Services Licence (AFSL) holder or an authorised representative; we do not provide advice to consumers. The adviser owns the advice and the licensing obligations attached to it. Every part of the platform is designed around that boundary.