How Ihjiz protects the platform and the data on it. This page describes what is in place today, in plain terms, and what is not yet. It is written for business owners, IT reviewers and security researchers.
Where we stand. Ihjiz has not yet completed an independent audit such as SOC 2 or ISO 27001. The controls below are real and in production; the certification is a roadmap item. If your procurement process needs a questionnaire answered, write to security@ihjiz.co.
1.Architecture and isolation
- Ihjiz is a multi-tenant platform: every business's data lives in the same database, separated by a business identifier that is enforced in the application on every query. A signed-in user can never address another business's records, and the check happens server-side, not in the browser.
- Three portals — customer, business and platform administration — share one API but carry different roles, and platform administrators do not see business data in day-to-day operation.
- Public booking pages and the embeddable widget expose only what a business chose to publish: services, availability, and the fields it asks customers to fill in.
2.Encryption
- All connections use TLS. Plain HTTP is not served.
- Databases, backups and file storage are encrypted at rest by our infrastructure providers.
- Secrets stored on your behalf — payment-gateway keys, messaging-channel tokens, AI provider keys, calendar tokens — are encrypted with AES-256-GCM before they are written to the database, under a key that lives only in the runtime environment, never in the code or the database. The key was rotated in July 2026 and can be rotated again without downtime.
- Passwords are stored as salted hashes; we never store or log them in clear text.
3.Signing in
- Passkeys (WebAuthn) for passwordless sign-in bound to the ihjiz.co domain.
- One-time codes by phone or email, and sign-in with Google or Facebook.
- Repeated failed attempts lock the account temporarily; lockouts are shared across servers.
- Users can see their active sessions and devices and revoke any of them. Staff mobile apps keep tokens in the operating system's secure keystore and can require biometrics to open.
- State-changing requests are protected against cross-site request forgery; cookies are HttpOnly, Secure and SameSite.
4.Access control inside your business
- Roles are built from per-module view, edit and delete permissions, and you can create your own.
- Sensitive actions carry their own gates: discounts above a cap need manager approval, payments can require approval before they settle, internal notes are never shown to customers.
- Every change to a booking, price, customer record or setting is written to an audit trail with who, when, and the previous value. Every view of a customer record is written to a data-access log. Both are available to your administrators.
5.Application security
- All input is validated with strict schemas on the server; database access goes through a typed query layer, not hand-written SQL.
- Outbound integrations (webhooks, custom endpoints) refuse private and internal network addresses to prevent server-side request forgery.
- Rate limits apply to sign-in, one-time codes, messaging and bulk operations.
- Dependencies are pinned and updated regularly; the build fails on type errors.
- Uploaded files are scanned for type, size-limited, stored outside the web root and served through signed URLs.
6.Payments
Card numbers never touch our servers. Payment forms are served by the provider — Stripe, HyperPay, Tap or PayPal — and we receive only a token and the result. Each business connects its own provider account, so customer funds settle directly to the business. Webhooks from providers are verified with their signing secrets before we act on them.
7.Availability and recovery
- The database is continuously backed up by our provider with point-in-time recovery.
- Background work — reminders, exports, follow-ups — runs through a persistent job queue with retries and a dead-letter list, so a transient failure does not lose a message.
- Service-level targets, maintenance and incident communication are described on the Service Levels page.
8.Data lifecycle
- You can export customers, appointments, invoices and most other records at any time.
- Retention periods are set out in section 8 of the Privacy Policy; deletion follows the Data Deletion page.
- The AI agent works with bounded conversation memory scoped to one business and one customer, and its usage is metered per plan.
9.Incident response
If we confirm a security incident affecting your data, we notify the owners of every affected business without undue delay and within 72 hours of becoming aware, with what we know, what we have done, and what you should do. We follow up as the picture becomes clearer, and we publish a summary once the incident is closed.
10.Reporting a vulnerability
We welcome reports from security researchers. Send them to security@ihjiz.co with steps to reproduce, the affected URL or endpoint, and the impact you believe it has. We acknowledge within 3 business days, keep you informed, and credit you if you wish once the issue is fixed.
- In scope: ihjiz.co, app.ihjiz.co, api.ihjiz.co and the staff mobile apps.
- Please do not: access or modify data that is not yours, run denial-of-service tests, send spam through the platform, or use social engineering against our staff or our customers. Create your own test business instead; the Free plan is enough.
- Safe harbour: research conducted in good faith within these rules will not lead to legal action from us. We do not currently run a paid bounty programme.