Security Policy

1. Overview

This Security Policy describes the technical and organisational controls ManageYourTax uses to protect customer data — including Consumer Data Right (CDR) banking data, personal information and business records. ManageYourTax is operated by NT Development Group Pty Ltd (ABN 95 676 608 610) and is governed by Australian law.

We design our systems around the principles of least privilege, defence in depth, data sovereignty and secure-by-default configuration.

2. Infrastructure & data residency

• All production infrastructure is hosted on Google Cloud Platform in the Sydney region (australia-southeast1)
• Application services run on Google Cloud Run, with autoscaling and revision-pinned deployments
• Primary data store is Google Firestore (Sydney); file storage is Google Cloud Storage (Sydney); authentication is Firebase Authentication
• No customer data leaves Australia. We do not use overseas data centres, processors or backups

3. Encryption

• In transit: all client and service-to-service traffic uses TLS 1.2 or higher with HSTS enforced
• At rest: data in Firestore and Cloud Storage is encrypted with AES-256 using Google-managed keys
• Secrets and API keys are stored as Cloud Run environment variables and never committed to source control

4. Authentication

• Sign-in is provided by Firebase Authentication via the AndGo platform identity service (OAuth 2.0)
• Supported methods: Google, Microsoft, email + password, and email magic link
• Sessions time out automatically after 30 minutes by default; users may configure between 15 minutes and 2 hours, or disable timeout
• Cross-tab sign-out is synchronised so signing out in one tab signs out all tabs
• Direct client-side use of legacy Firebase auth methods is blocked by a CI guardrail to prevent regressions

5. Authorisation & access control

• Every Firestore read and write is governed by server-side Security Rules, which enforce per-business isolation: a user can only access businesses they own, are a team member of, or have been explicitly invited to
• Role-based access within a business: owner, member and accountant roles with distinct permission sets
• Server-side API routes verify Firebase ID tokens on every request and cross-check business ownership before any data access
• Privileged access to production infrastructure is restricted to a small number of named administrators and protected by Google account 2FA

6. Multi-tenant isolation

Customer data is stored in per-business document subtrees. Firestore Security Rules and server-side ownership checks make it impossible for one tenant's data to be read or modified by another tenant's users. For CDR banking data, every consent is scoped to a single business and each business holds its own consent record with Wych.

7. Application security

• Built with TypeScript in strict mode; the production build fails on any type error
• Input validation at every API boundary; outputs sanitised to prevent injection and XSS
• Third-party scripts loaded on critical user flows (auth, payment) are explicitly insulated via data-no-track attributes to prevent interference with form submission
• Dependencies are scanned for known vulnerabilities; security patches are applied promptly

8. Audit & logging

• Request logs and application logs are written to Google Cloud Logging and retained for at least 30 days
• Accounting changes (invoice edits, transaction edits, journal entries, BAS lodgements) are captured with audit trails in the application database
• Admin actions (broadcast emails, role changes, business deletions) are recorded in a platform activity log

9. Backup & recovery

Firestore data is protected by Google Cloud's native redundancy across multiple zones within the Sydney region. We can perform point-in-time exports for disaster recovery and migration scenarios. Customer-initiated data exports are available on demand.

10. Penetration testing

Independent third-party penetration testing of the production environment is part of our security program. The first full external penetration test will be commissioned prior to commercial CDR data access going live, and thereafter testing will be conducted at least annually. Material findings are remediated and reverified before sign-off.

11. Incident response

• Suspected security incidents are triaged immediately on discovery
• Confirmed incidents involving personal information are notified to the OAIC under the Notifiable Data Breaches scheme within the statutory timeframe
• Incidents involving CDR data are notified to Wych (our CDR Principal), the ACCC and the OAIC as required by the CDR Rules
• Affected users are notified directly without undue delay once the scope of the incident is confirmed

12. Vulnerability disclosure

We welcome reports of suspected security vulnerabilities from independent researchers. Please email andy@interetail.com with a clear description, reproduction steps and any supporting evidence. We acknowledge receipt within 2 business days, work toward a fix on a priority basis, and will credit researchers in our remediation notes unless asked not to. We ask that researchers do not exploit, retain or disclose vulnerabilities publicly before remediation.

13. Third-party processors

We rely on a small set of trusted service providers, each contracted under terms consistent with the Australian Privacy Principles and (where applicable) the CDR Rules:

• Google Cloud / Firebase — infrastructure, database, authentication, file storage (Sydney region)
• Activate Wych Pty Limited — Consumer Data Right Principal for Open Banking
• Stripe — subscription payment processing
• SendGrid — transactional email delivery
• Anthropic — AI inference for transaction categorisation and report generation. Customer data is not used to train AI models
• Twilio — SMS notifications for quote and invoice workflows

14. Changes to this policy

We may update this policy as our systems evolve. Material changes will be notified in advance via email or in-product notice.

15. Contact