Security & data handling

Per-client data isolation

Every domain table carries a client_id and is protected by row-level security enforced in the database, not in application code. A signed-in operator's queries are filtered to their own agency's rows by policy; there is no request path — including our own server functions — that can widen that scope without a service-role credential.

Cross-tenant reads by platform staff are only possible through an explicitly audited path, which writes an immutable audit_log entry naming the actor, the target agency, and the resource read.

Card data never touches our infrastructure

Payments run through a merchant-of-record provider. Card entry happens in the provider's PCI-DSS compliant environment; Immacél stores only the resulting customer and subscription identifiers. No primary account number, expiry, or CVC is ever transmitted to, logged by, or persisted on Immacél servers or in our database.

Verified webhooks and idempotent transactions

All payment-related webhooks are signature-verified against the raw request body using a timing-safe comparison before any handler logic executes; unsigned or mismatched requests are rejected with 401 and never processed. Subscription tier is written by the verified webhook alone — never by client code, and never by a self-service control in the product.

Each transaction carries a unique idempotency key, so a retried or duplicated provider delivery cannot double-charge, double-credit, or re-apply a tier change.

Two-factor authentication on financial surfaces

Time-based one-time-password enrolment is available in Workspace settings and is required for operators who need access to billing and the performance-fee ledger. Enrolment is bound to the operator's identity at the authentication layer, not to a role flag in application data.

Billing is never gated

Any client charged a performance fee can read the full ledger behind that fee, at every tier. We treat withholding billing visibility from a paying client as a defect, not a packaging decision.

What is not in place yet

Stated plainly, so no one assumes otherwise: Immacél holds no SOC 2 Type I or Type II report, no ISO 27001 certificate, and no HIPAA or PCI attestation of its own (card handling is delegated entirely to the merchant-of-record provider). We do not currently run an external penetration test on a fixed schedule, we do not offer customer-managed encryption keys, and we do not yet publish an uptime SLA with financial remedy. Data is stored in our cloud provider's managed Postgres with encryption at rest and in transit; regional data-residency selection is not available.

Any of the above that changes will be updated on this page with the date it changed. We will not describe a control here before it is actually running.

Reporting a vulnerability

Send findings to security@immacel.com with reproduction steps. We acknowledge reports and will confirm remediation once a fix ships. We do not currently operate a paid bounty programme.