How we secure your data

• In transit: TLS 1.2 minimum across all public endpoints, HSTS enabled, modern cipher suites only. Internal service-to-service traffic over authenticated, encrypted channels.
• At rest: AES-256 on the database volume, on the storage bucket and on snapshot backups. Secrets and OAuth refresh tokens are stored with an additional column-level encryption layer using pgcrypto or KMS-managed keys.
• Passwords: hashed with bcrypt. Cleartext passwords are never logged or stored.

Every meaningful state change in the platform writes a row to the audit log: who, when, what entity, what changed, the request identifier and the user-agent. Audit log entries are immutable once written; they can be appended to but not retroactively edited. Exports of the audit log are available to practice administrators for their own records and incident investigations.

• Source code lives in a private repository with branch protection on the main branch and required code review for production changes.
• Dependencies are scanned continuously for known vulnerabilities. Critical-severity issues are remediated within 7 days; high within 30.
• Static analysis (mypy, eslint, type checks) and a full automated test suite run on every change before merge.
• Secrets are never committed; we use a managed secret store and pre-commit hooks that block secret-shaped strings.
• Production deploys are immutable, traced to a specific git commit, and reversible by re-deploying the prior revision.

We collect application, infrastructure and security logs into a central observability pipeline. Personally identifying information is scrubbed before logs leave the application boundary. Alerts fire to an on-call rotation for production errors, anomalous authentication patterns, rate-limit breaches and integrity failures (for example, a bank reconciliation that fails to balance to the imported statement).

We maintain a written incident response plan covering detection, triage, containment, eradication, recovery, customer communication and post-incident review. Where an incident gives rise to a notifiable data breach under Part IIIC of the Privacy Act 1988 (Cth), we will notify affected individuals and the OAIC as soon as practicable and in any event within the statutory timeframe. Customers are notified by email to workspace administrators.

The current list of sub-processors and the categories of data they handle is published in section 6 of our Privacy Policy. Each sub-processor has been assessed for its security posture and is contractually bound to handle data consistently with the Australian Privacy Principles.

Independent third-party penetration testing, SOC 2 Type II attestation and ISO/IEC 27001 certification are on our roadmap and will be commissioned as our team and customer base grow. We will publish updates to this page as each milestone is reached. In the meantime, the current control set and our planned assurance timeline can be discussed under NDA — reach us at info@reconlink.com.au.

The strongest controls we deploy depend on customers using the Service responsibly. We ask each practice to:

• Use unique, strong passwords for ReconLink and enable multi-factor authentication once available;
• Keep Authorised User accounts current — disable users who leave the practice promptly;
• Treat the per-client email inbox addresses as unguessable but not secret; if you suspect one has been shared, rotate it from the client’s settings page;
• Review the audit log periodically and report suspected unauthorised access to info@reconlink.com.au.

If you believe you have discovered a security vulnerability in ReconLink, please report it to info@reconlink.com.au with reproduction steps. We commit to acknowledging legitimate reports within two business days, keeping you informed during remediation, and not pursuing legal action against good-faith security research conducted in accordance with the principles of responsible disclosure.