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.

Certifications: HAMANI is not currently SOC 2 or ISO 27001 certified, and we do not claim to be. Our controls are built to support a SOC 2 program, which can be initiated on an enterprise engagement — but no report exists today.

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.

DataPersonalOn account deletionRetention
Contacts (your audience)
Email/mobile/name + consent basis you recorded.
yeserasedKept until you delete it or delete your account.
Campaign enrolments
Which contact is in which campaign + step progress.
yeserasedKept until you delete it or delete your account.
Campaigns
Your campaign definitions and copy.
noerasedKept until you delete it or delete your account.
Audiences
Audience filter definitions.
noerasedKept until you delete it or delete your account.
Content
Drafted content items.
noerasedKept until you delete it or delete your account.
Templates
Reusable message templates.
noerasedKept 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.
noretainedKept as a one-way hash specifically so opt-outs can never be undone.
Wallet ledger
Credit/debit history underpinning tax invoices.
noretainedKept only as long as the law requires (e.g. tax records), then removable.
Tax invoices
GST invoices — retained as long as tax law requires.
noretainedKept 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.
noretainedKept only as long as the law requires (e.g. tax records), then removable.
Usage records
Per-send metering counters.
noerasedKept for day-to-day operation and cleared when no longer needed.
Team seats
Team member emails + roles.
yeserasedKept until you delete it or delete your account.
Support & governance requests
Hardship/deletion requests — kept as proof the right was honoured.
yesretainedKept only as long as the law requires (e.g. tax records), then removable.

Sub-processors

ProviderPurposeLocation
Google Cloud (Firebase / Firestore)Primary application databaseSydney, Australia (australia-southeast1), verified at go-live
CloudflareApplication hosting (Workers), CDN, edge securityGlobal edge network
StripePayment 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 engineSydney, Australia (ap-southeast-2)
AnthropicAI assistant (drafting & translation) — does not train on the text sent to itUnited 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