Security
Effective 20 May 2026 · Updated 9 June 2026
Security is a foundation, not a feature. HAMANI CRM is built so that Customer Data is hard to lose and hard to leak.
1. Architecture
- Multi-tenant from day one — every record carries a
tenant_idand rules enforce isolation - Deny-by-default authorization at the database layer (Firestore Security Rules)
- TLS in transit, AES-256 at rest, managed-key encryption for backups
- Region-locked data — primary data in Sydney (australia-southeast1)
- Edge served via Cloudflare for DDoS resilience and low latency
2. Identity
- Firebase Auth with hardened session policies
- Magic-link and OAuth sign-in (Google, Microsoft)
- SSO and SCIM for Enterprise plans
- Per-tenant audit log of authentication events
3. Operational security
- Least-privilege access for all engineers
- Mandatory 2FA on every admin surface (Cloudflare, Firebase, Stripe, GitHub)
- Pre-deploy secret scanning
- Content Security Policy + HSTS + frame-ancestors lockdown
- Cloudflare WAF and bot management
4. Vendor management
We maintain a current sub-processor list and review SOC2 / ISO posture of all data-handling vendors. A copy is available on request to enquiries@hamanicrm.com.au.
5. Responsible disclosure
We welcome security research. If you believe you have found a vulnerability, please email enquiries@hamanicrm.com.au with a clear description and reproduction steps. We will acknowledge within two business days and aim to triage within five. Please do not publicly disclose until we have had a reasonable window to remediate.
Our machine-readable security contact lives at /.well-known/security.txt.
6. Incident response
We notify affected customers without undue delay when we determine that an incident is likely to have caused material risk, and we report eligible data breaches to the OAIC as required under the Notifiable Data Breaches scheme.