Built for boards that get audited.
Mithaq publishes the controls implemented in the current product path and separates them from deployment-specific responsibilities. Validate the final network, identity, backup, support and incident design against your own requirements.
Tenant isolation
Each tenant uses a tenant-scoped data directory. Tenant-aware read and write helpers take the slug from request context set by middleware, and host-isolation tests exercise the public boundaries before release.
- Per-tenant data dir, not a shared multi-tenant database
- AsyncLocalStorage carries the tenant slug across every request
- Middleware resolves slug from request host (or the on-prem env pin)
- Administrative activity is subject to role checks and audit events
Authentication
OTP login over email or WhatsApp. No passwords stored, no password reset flow, no phishing surface. Session cookies are HttpOnly, Secure, SameSite=Lax, signed.
- OTP codes expire within 10 minutes
- Rate-limited per phone/email + per IP
- Sessions invalidated on role change or admin disable
- Enterprise identity requirements are confirmed during implementation
Authorisation
Per-tenant role matrix at data/tenants/<slug>/roles.json. Each role declares which modules it can read, create, update, delete. hasPermission() is the canonical check on every mutating endpoint.
- Module × action permission grid, fully editable per tenant
- Sector + sub-sector module visibility runs on top
- requiresPlan gate: Free tenants cannot enable Pro modules even via features.json
- Superadmin role only on the Mithaq operator tenant; cloud customers do not get it
Audit trail
Administrative mutation paths use audit helpers that append actor, action, time and request context to the tenant audit log. Buyers should validate the events required by their own control framework.
- Append-oriented event records
- Includes diff of changed fields, not full record dumps
- Export paths are available for supported audit records
- Required operator-access evidence should be tested during evaluation
Transport + storage
TLS 1.2 minimum, TLS 1.3 negotiated where supported. Cloudflare Full (Strict) origin certificate. HTTP/2 to all browsers; HTTP/3 negotiated.
- min_tls_version: 1.2 (Cloudflare zone setting)
- always_use_https + automatic_https_rewrites enforced
- HSTS preload candidate (subject to operator opt-in per zone)
- Backup encryption and retention are deployment responsibilities
Data residency
The current hosted path uses EU infrastructure behind Cloudflare. The single-tenant on-premise path runs on customer-controlled infrastructure. Final data boundaries depend on identity, notification, integration, support, backup and update choices.
- EU primary, Muscat edge, proximity + latency to Omani users
- On-Prem mode pins the application to a configured tenant
- External data flows must be documented for the selected deployment
- Sub-processor list public on the DPA page
Operations
Critical concurrent writes use file locks and the hosted service runs under process supervision. Build, SEO and host-isolation checks run in the release workflow. Backup operation remains deployment-specific.
- withFileLock() wraps every concurrent-write critical section
- The shared server resolves tenant context from each request host
- Release checks cover both Mithaq and fencing.om public surfaces
- On-Prem ships as Docker compose with documented backup commands
Incident response
Incident notification, escalation, reporting and recovery obligations must be defined in the applicable DPA and service terms. The public health endpoint exposes a limited service-status snapshot.
- Tenant contacts and notification channels are agreed during onboarding
- Public status snapshot at /api/mithaq/health.json
- Required reporting timelines belong in the signed agreement
- Recovery and service remedies depend on the selected service terms