Sensitive data,
treated like it.

• Password hashing — bcrypt via Supabase Auth. We never see, log, or store plaintext passwords.
• JWT sessions — Short-lived access tokens with automatic refresh; per-request verification at the API edge.
• Two-factor authentication (TOTP) — TOTP MFA via any standard authenticator app (Google Authenticator, 1Password, Authy, Microsoft Authenticator). Secrets stored encrypted in the same AES-256-GCM scheme as TFNs.
• Passkeys (WebAuthn) — Sign in with Touch ID, Face ID, Windows Hello, or a hardware security key. Passkeys are phishing-resistant — they only work on Finance Frank, even if a lookalike site asks for one. Multiple passkeys per account, manage in Settings → Preferences.
• Mandatory MFA for practice tier — Practice-tier accounts (accountant / planner / broker firms) cannot sign in until MFA is enrolled — there is no opt-out for accounts holding client KYC and TFN data. Either TOTP or passkey satisfies the requirement. Consumer-tier MFA remains optional but encouraged.
• Account lockout — Five failed sign-in attempts trigger a 15-minute lockout to defeat credential stuffing.
• Row-level security — PostgreSQL RLS policies enforce per-user isolation at the database layer. Even if the application were bypassed, the database refuses cross-user reads.
• Admin endpoints — Restricted to a single configured admin user ID. Service-role keys are never exposed to the client.

• Input sanitisation — Pydantic schema validation at the API boundary; parameterised queries throughout (no string-concatenated SQL).
• Rate limiting — Per-endpoint limits — auth: 5/min, AI chat: 10/min, write endpoints: 60/min — to prevent abuse and brute force.
• Security headers — HSTS (1 year, includeSubDomains), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a strict Permissions-Policy, and Cross-Origin-Opener-Policy + Cross-Origin-Resource-Policy on HTML-serving origins.
• Content Security Policy — Nonce-based CSP on the web app (per-request nonce minted by Next.js middleware) blocks injected scripts. Static CSP on the marketing site. The API serves a maximally restrictive policy (default-src none) for the rare HTML surface.
• CSRF + CORS — CORS restricted to authorised origins; CSRF protection on state-changing endpoints.
• Tamper-evident audit logging — Mutating API operations log to a server-side audit trail with INSERT-only RLS — even with a compromised service-role key, audit rows cannot be UPDATEd or DELETEd through the application. Logs retained 2 years then de-identified (monthly cron enforces this — see Privacy Policy s 7).
• Dependency hygiene — Lockfiles for both backend (pip) and frontend (pnpm); CI runs the test suite + typecheck on every push. Dependabot opens weekly PRs for minor/patch updates; pre-commit hook blocks any AWS / Stripe / Anthropic / OpenAI / Resend key, private key block, or .env file from being staged.

• Per-user isolation — PostgreSQL RLS at the database tier. Logical isolation enforced at the data layer regardless of what the application does.
• Per-entity permissions — You can scope shared access to specific entities (e.g. invite your accountant to your business entity without exposing your personal data).
• Practice tier sharing — When you accept a practice invite, only the data tables you grant are readable. Per-practice-member RLS — a staff member at Practice A cannot see Practice B's clients. Every read is audited; you can revoke access from settings at any time.
• Tipping-off-safe messaging — Practitioner-only message flag ensures AML/CTF-related notes are never visible to the client (consistent with s 123 of the AML/CTF Act).
• Sign-off audit trail — BAS approvals and engagement letter sign-offs capture authenticated user identity, server-recorded timestamp, IP, user-agent and a SHA-256 hash of the verbatim declaration text. Retained 5 years per section 30 of the Tax Agent Services (Code of Professional Conduct) Determination 2024 and TPB(I) 47/2024.

• Privacy Act 1988 (Cth) — We comply with the Australian Privacy Principles, the Privacy (Tax File Number) Rule 2015, and the Privacy and Other Legislation Amendment Act 2024 (statutory tort, automated-decision-making transparency obligation).
• APP 11 — technical AND organisational measures — The technical controls on this page are paired with organisational measures: documented info security policy, least-privilege access reviews, vendor due-diligence procedure, documented incident-response plan, periodic risk assessment, director-level oversight.
• Notifiable Data Breaches scheme — We assess any suspected breach within the s 26WH window (target: 7-14 days, hard limit 30) and notify both the OAIC and affected individuals within 72 hours of confirming a notifiable breach.
• AML/CTF Tranche 2 (from 1 July 2026) — For practice-tier customers becoming reporting entities, Frank captures KYC, beneficial ownership, sanctions screening (DFAT + OFAC + UN), PEP self-declaration + practitioner-review queue, AML record register (7-year retention), Evidence Pack PDFs (for SMR support) and TTR drafts. SMRs are written directly in AUSTRAC Online — Frank stays out of the SMR data flow to support s.123 tipping-off compliance. Lodgement remains the practice's responsibility.
• Cyber Security Act 2024 — Where ransomware-payment reporting under Part 3 of the Cyber Security Act 2024 is triggered, we comply with those reporting obligations and notify any Controller affected — see DPA cl 12.

• New-device sign-in alerts — Every successful sign-in is checked against a fingerprint of (browser + IP /24 prefix). The first time a new device signs in, you get an email naming the device, IP, and time, with a one-click link to your security settings.
• Sensitive account-change alerts — Password change, MFA disable, and (when available) email change each fire an immediate email to the account owner. If the change wasn't you, the alert tells you exactly what to do — change password, sign out everywhere.
• Bulk export detection — More than 5 export requests in a 5-minute sliding window triggers an "unusual export activity" email naming the count, most recent export, and IP. Catches data exfiltration where an attacker has session access but no other privileged credentials.
• No opt-out for security alerts — These emails cannot be unsubscribed from — they are operational security notices, not marketing. Marketing opt-outs are handled separately under the Spam Act 2003 (see Privacy Policy s 10).

• Primary recovery — Supabase point-in-time recovery (PITR) on a 30-day rolling window. This is the first line of defence for accidental data loss within the active project.
• Off-site daily snapshot — Every customer-data table is dumped daily at 4:30am AEST as JSONL + gzip + AES-256-GCM-encrypted with a key SEPARATE from the application encryption keys. Uploaded to an S3-compatible bucket (Cloudflare R2) in a different cloud and region than primary Supabase. Compromise of one set of keys does not expose the other.
• Defence in depth at rest — On top of our application-layer AES-256-GCM, the bucket itself enforces SSE-AES256. Two independent encryption layers; both have to fail for the backup to be readable in plaintext.
• Nightly integrity check — Within 30 minutes of each backup, an automated job downloads the manifest + a sample table, decrypts with the production key, parses, and verifies the row count matches the manifest claim. If anything fails — wrong key, missing data, format drift — the founder gets an email immediately, so a degraded pipeline is caught within ~24 hours rather than at restore time.
• Restore drill cadence — Quarterly — we restore a known backup into a sandbox Supabase project end-to-end and document any gaps. A backup pipeline that hasn't been restore-tested is functionally an unverified pipeline. The founder gets an automated reminder on the 1st of January, April, July, and October.
• TPB 5-year retention — Engagement letter and BAS sign-off events are archived monthly into the same off-site bucket under a separate prefix, retained for 5 years per section 30 of the Tax Agent Services (Code of Professional Conduct) Determination 2024 and TPB(I) 47/2024.

Our complete sub-processor list — with each provider's purpose, recipient location, data hosting region and contractual safeguards — lives in the Privacy Policy. Every sub-processor we use is independently audited: Supabase, Anthropic, OpenAI, Stripe, Render, Vercel and Resend are all SOC 2 Type II attested; Render adds ISO 27001; Stripe adds PCI-DSS Level 1. Practice-tier customers receive at least 30 days' written notice before any new sub-processor is added, with the right to object on legitimate grounds (per the DPA).

We follow the Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act 1988. We assess any suspected breach within the statutory s 26WH window, notify the OAIC and affected users within 72 hours of confirmation, and move immediately to contain and mitigate harm. Pre-confirmation, we may also send Controllers an early-warning notice for security incidents under investigation.

Email security@financefrank.ai with enough detail to reproduce. Please don't publicly disclose before we've had a chance to address it, and don't access or modify other users' data. We acknowledge responsible disclosures within 24 hours and credit reporters who want it.