Trust Center

How AWMZA Cybersecurity protects your data

This page lists our real, current security controls — and is equally honest about what is still in progress. Nothing here is a marketing claim: every item is either live today, a documented follow-up, or clearly marked not yet done.

Last updated: 6 September 2026 · Questions: security@awmza.com · security.txt

Live today Documented follow-up Not yet in place

On this page

  1. Encryption
  2. Authentication & access
  3. Tenant isolation
  4. Incident response
  5. Business continuity / disaster recovery
  6. Data retention & deletion
  7. Vulnerability management
  8. Hosting & sub-processors
  9. Certifications & audits
  10. Report an issue / contact

1Encryption Live

  • All traffic is served over HTTPS/TLS, with automatic HTTP→HTTPS redirect and HSTS enabled.
  • Account passwords are hashed with scrypt (a memory-hard KDF). Plaintext passwords are never stored.
  • SSO/SAML client secrets are encrypted at rest (Fernet/AES-based). Plaintext secrets are never stored.
Disk-level database encryption currently relies on our hosting provider's default disk encryption. A formal application-level, at-rest encryption document is a follow-up item — it is not yet written as a standalone policy.

2Authentication & access Live

  • Multi-factor authentication: authenticator-app TOTP and email one-time codes, both supported.
  • Progressive lockout on failed logins (3 fails → 10 min lock, 5 → 30 min, 6 → 90 min) and session-fingerprint mismatch triggers an automatic session revoke.
  • Enterprise-plan customers can connect their own identity provider — Okta, Azure AD, Google Workspace and others — via OIDC or SAML 2.0, with SSRF-guarded endpoint validation and encrypted secret storage.
Current SSO/SAML scope is single-owner-account login. Multi-employee "team members" SSO for a whole company is a planned follow-up — it requires a full role-permission audit of every privileged endpoint first, to avoid any accidental privilege escalation, so we are deliberately not rushing it.

3Tenant isolation Live

Every data query is scoped by account/tenant identifier. This is enforced in code across the monitoring, compliance-report and agency (white-label) modules, and is covered by dedicated automated tests that specifically check one tenant can never read another tenant's data.

4Incident response LiveFormal policy: follow-up

  • Detection: continuous domain monitoring and an AI security assistant track findings per customer domain in real time.
  • Containment: no automated containment action runs without a permission gate — every autonomous action above the lowest advisory level requires an explicit human-approved decision, logged and auditable.
  • Escalation: issues that cannot be resolved automatically are escalated directly to the founder with cause and proposed fix.
  • Audit trail: every action is recorded in a tamper-evident audit log (who/what/when/result).
A formal written customer-notification timeline (how many hours before affected customers are informed) is not yet published — that is a documented follow-up item.

5Business continuity / disaster recovery Partially formal

  • Every change to a live file is backed up first, outside the public web root.
  • Every new feature ships with automated tests, and services are restarted and re-verified twice before being considered done.
We currently run a single-region server setup, with no multi-region failover. Formal RTO/RPO targets are not yet defined — we consider multi-region infrastructure premature at our current stage, and will invest there once customer volume justifies it. This is stated honestly rather than implied otherwise.

6Data retention & deletion Live

Account-deletion requests go through a 30-day recovery window before permanent deletion — enforced in code, with no manual step that could be skipped.

A fixed retention schedule for scan-history and audit logs (e.g. "audit logs kept for 2 years") is not yet published as a formal number — this is a common procurement question and is on our follow-up list.

7Vulnerability management Informal today

Server OS packages are updated regularly and Python dependencies are pinned. We do not yet run a formal, automated vulnerability-scanning pipeline with a published SLA — an independent third-party penetration test is researched and planned (see Certifications below) but not yet scheduled.

8Hosting & sub-processors Live

  • Hosting: a single server with Hetzner (Germany-based).
  • Payments: Stripe processes payments; Stripe's webhook only confirms events back to us — card and payment data never reach our server.
  • Email: our own mail infrastructure (mail.awmza.com) — no third-party email sub-processor.

9Certifications & audits Not yet certified

We are honest about this: AWMZA Cybersecurity does not currently hold ISO 27001 or SOC 2 certification, and has not yet undergone an independent third-party penetration test. Where our marketing pages mention compliance-related badges, they describe aligned controls, not a third-party certificate — we will not claim a certification we do not hold.

We have researched the realistic cost and timeline for both ISO 27001 and SOC 2, and for an independent pen test, and starting that process is an active decision on our roadmap. We will update this page the day any certification or audit is actually completed — not before.

10Report an issue / contact

Found a security issue, or need a completed security questionnaire (SIG/CAIQ/VSA) for your procurement process? Email security@awmza.com, or see our security.txt for responsible-disclosure details.