HAMANI Marketing
Trust Centre
Straight answers to the questions enterprise buyers ask. Everything marked In place is implemented in the product today. Items on the Roadmapare not done yet and are labelled as such — we don’t claim controls we haven’t built. See also the Security page, the DPA template, and the SLA template.
Encryption
- Is data encrypted in transit?In place
Yes. All traffic is HTTPS with HSTS; a Content-Security-Policy (frame-ancestors 'none', object-src 'none', pinned connect-src) and standard security headers are set on every response.
- Is data encrypted at rest?In place
Yes. Application data is encrypted at rest by the cloud provider (Google Cloud Firestore).
- How are passwords stored?In place
Only as a one-way PBKDF2-SHA256 hash (600,000 iterations, per-user salt, versioned). Plaintext passwords are never stored.
Access control
- Is there role-based access control?In place
Yes. Configurable roles (owner / admin / manager / viewer) with a permission matrix enforced server-side on every write.
- Can access be granted and revoked (joiner-mover-leaver)?In place
Yes. Invite, role-change, and immediate revoke; a revoked member's live session stops working at its next request.
- Do you support enterprise SSO?In place
Yes. Per-tenant SAML 2.0 and OIDC federate your identity provider into HAMANI; HAMANI remains the system of record. Just-in-time provisioning maps users to roles.
- Do you support signing in with Google or Microsoft?In place
Yes. "Continue with Google" and "Continue with Microsoft" (both OIDC, RS256/JWKS/nonce-verified; Microsoft is single-tenant/Entra-bound) are available alongside email+password. HAMANI remains the system of record for the account and session.
- Do you support passwordless / biometric sign-in (passkeys)?In place
Yes. WebAuthn/FIDO2 passkeys (Face ID, Touch ID, Windows Hello, Android) register to an existing account; the biometric never leaves the device — we store the credential's public key, signature counter and the label you give it, erased with the account on deletion. Every assertion is verified (origin, single-use challenge, user-verification, signature) before a session is issued. Password remains a fallback.
- Are new accounts email-verified, and is there a self-serve password reset?In place
Yes. A new workspace must confirm its email through a single-use verification link (valid 24 hours) before it can be signed in to; password resets use a single-use link valid 1 hour. Only a one-way SHA-256 hash of each token is stored, a newer link replaces the older one, both flows are rate limited per account and per IP with enumeration-safe responses, and token records are erased with the account.
- Is multi-factor authentication available?Roadmap
Not natively yet for password accounts — this is on our roadmap. Passkeys provide device-bound biometric sign-in today, and enterprise tenants can enforce MFA at their own identity provider via SSO.
Tenant isolation
- How is customer data isolated?In place
Every record is scoped to a tenant id; database rules are deny-by-default and all writes go through the server. Sub-accounts and team access are isolation-tested (IDOR suites).
Abuse prevention
- Do you rate limit and prevent brute force?In place
Yes. Per-key/per-IP rate limiting on auth, public API, and SSO entry; sign-in lockouts on repeated failure.
Audit & logging
- Is there an audit log, and can we export it?In place
Yes. Access and state-changing actions are recorded per tenant in a tamper-evident audit log and are exportable as machine-readable NDJSON.
Incident response
- How are incidents detected and communicated?In place
Self-healing detects provider failures (circuit breakers), queues sending rather than dropping it, and logs plain-English incidents. Enterprise tenants can register an incident email/webhook.
- What is your data-breach process?In place
We operate under the Notifiable Data Breaches scheme (Privacy Act 1988, Part IIIC): eligible breaches are assessed and notified. A target notification window is set in the DPA.
Monitoring
- Is there a status page?In place
Yes — live component status at /status. We do not publish a historical uptime percentage until an independent external monitor is in place (on the roadmap).
- Is there independent external uptime monitoring?Roadmap
Not yet. We show live component status but do not quote a historical uptime figure until an independent monitor substantiates it.
Data governance
- Can customers export their data?In place
Yes. A machine-readable NDJSON export of the whole workspace, owner-initiated and audited.
- Can data be verifiably deleted?In place
Yes. Hard-delete erases personal-data collections, RE-READS to verify zero remain, and writes a retained deletion record as proof.
- Is customer data used to train AI models?In place
No. Your contact list and individual contact details are never sent for training or otherwise. The AI assistant sends the campaign text you ask it to draft/translate, plus an aggregate audience summary (a contact count and your top tag labels — never names or emails), to Anthropic's API, which does not train on it.
- Where is data stored (residency)?In place
Primary application data is provisioned in Sydney, Australia (Google Cloud Firestore, australia-southeast1) per our provisioning standard, verified at go-live. Some sub-processors process limited data overseas under APP 8.
Attestations
- Do you have SOC 2?Not held
No. We are not SOC 2 certified. A SOC 2 program can be initiated on an enterprise engagement; our controls are built in code to support one, but no report exists today and we do not claim one.
- Do you have ISO 27001?Not held
No. Not certified. Same position as SOC 2 — the underlying controls exist; the certificate does not.
Assurance
- Do you perform penetration testing?Roadmap
Security-critical code (e.g. the SSO/SAML verifier) is reviewed adversarially in-house; an independent external penetration test is on the roadmap and not yet completed.
Resilience
- What are your backup and disaster-recovery arrangements?Roadmap
Application data is on managed cloud infrastructure with the provider's durability guarantees. A formally documented and tested DR plan with stated RPO/RTO is on the roadmap.
People
- Do staff complete security training?Roadmap
A formal, recurring security-training program is on the roadmap as the team grows.
Data retention schedule
What we hold, whether it contains personal information, whether it is erased on account deletion, and for how long we keep it.
| Data | Personal | On account deletion | Retention |
|---|---|---|---|
| Contacts (your audience) Email/mobile/name + consent basis you recorded. | yes | erased | Kept until you delete it or delete your account. |
| Campaign enrolments Which contact is in which campaign + step progress. | yes | erased | Kept until you delete it or delete your account. |
| Campaigns Your campaign definitions and copy. | no | erased | Kept until you delete it or delete your account. |
| Audiences Audience filter definitions. | no | erased | Kept until you delete it or delete your account. |
| Content Drafted content items. | no | erased | Kept until you delete it or delete your account. |
| Templates Reusable message templates. | no | erased | Kept until you delete it or delete your account. |
| Unsubscribe list One-way SHA-256 hashes of opt-outs (no email/phone stored) kept so a deleted-then-recreated list can never re-contact someone who left. | no | retained | Kept as a one-way hash specifically so opt-outs can never be undone. |
| Wallet ledger Credit/debit history underpinning tax invoices. | no | retained | Kept only as long as the law requires (e.g. tax records), then removable. |
| Tax invoices GST invoices — retained as long as tax law requires. | no | retained | Kept only as long as the law requires (e.g. tax records), then removable. |
| Audit log Access + action history, including the record of your deletion request. | no | retained | Kept only as long as the law requires (e.g. tax records), then removable. |
| Usage records Per-send metering counters. | no | erased | Kept for day-to-day operation and cleared when no longer needed. |
| Team seats Team member emails + roles. | yes | erased | Kept until you delete it or delete your account. |
| Support & governance requests Hardship/deletion requests — kept as proof the right was honoured. | yes | retained | Kept only as long as the law requires (e.g. tax records), then removable. |
Sub-processors
| Provider | Purpose | Location |
|---|---|---|
| Google Cloud (Firebase / Firestore) | Primary application database | Sydney, Australia (australia-southeast1), verified at go-live |
| Cloudflare | Application hosting (Workers), CDN, edge security | Global edge network |
| Stripe | Payment processing for top-ups (card data handled by Stripe; we never store cards) | United States / global |
| Amazon Web Services (SES) | Transactional & campaign email delivery, via HAMANI's own Email engine | Sydney, Australia (ap-southeast-2) |
| Anthropic | AI assistant (drafting & translation) — does not train on the text sent to it | United States |
Security questions or a questionnaire to complete? Email security@hamanimarketing.com.au. Report a vulnerability the same way — we’ll respond in good faith. Our machine-readable answers live in security.txt.
HAMANI PTY LTD · ACN 696 864 981 · ABN 48 696 864 981