Security

Security is a first-class design constraint at RegSpace. Clients entrust us with confidential internal policies, so we assume hostile conditions and defend in depth. We describe below what is in place today and, where relevant, what is on the roadmap; we do not claim controls we have not implemented.

Tenant isolation

• Schema-per-tenant. Each tenant has its own Postgres schema (tenant_<uuid>); no shared table holds tenant-scoped business data. The tenant id is resolved from an authenticated, validated session and used to select the schema, so a mis-scoped query fails to resolve rather than returning another tenant’s rows.
• Tenant-scoped agents. Every weekly agent run operates against a single tenant’s schema; it never reads across tenants.
• Defense in depth (in progress). We are adding database-layer access policies on top of schema separation, so isolation does not rest on application-layer scoping alone.

Encryption

• TLS in transit on all hosts, with HSTS enabled.
• Encrypted at rest by the underlying platform (Google Cloud). Customer- managed encryption keys (CMEK) are on the roadmap.

Authentication and access

• SSO via SAML / OIDC and SCIM user provisioning for organisations, so your identity provider remains the source of truth.
• MFA for your users is enforced by your own identity provider through SSO; MFA is required for all RegSpace staff accounts.
• Role-based access in the portal (viewer / contributor / approver / admin), with money- and entitlement-bearing fields protected at the database grant level so they cannot be self-escalated.
• Production access is restricted to a small team and is audited.

Model-provider controls

• LLM inference via enterprise endpoints; we do not train or fine-tune on client data.
• Every digest item links to its primary source so your team verifies it directly. Nothing is auto-published; a human keeps or deletes each item, and every redline is reviewed before it is applied.

Audit trail

Every material agent action (what was classified and drafted, with the model and version that produced it) and every human keep/delete decision is recorded in a per-tenant hash-chained audit log (record[n].prev_hash = sha256(record[n-1])). The chain is independently re-verifiable on demand, so after-the-fact tampering is detectable. Anchoring each chain’s tip to retention-locked storage (for whole-chain tamper-evidence) is built but not yet enabled in production.

Data residency

• Tenant data is hosted in europe-west2 (London) today; a US data region (us-central1) is on the roadmap.
• Regulatory coverage spans EU, UK, US (federal + priority states), and Australia; coverage and hosting region are independent.

Software supply chain

• Dependencies are pinned to explicit versions across the monorepo.
• Container images are built from pinned base images, and production secrets live in Google Secret Manager — never in source.
• Automated dependency scanning, signed commits, and image signing are on our roadmap, sequenced with our CI rollout.

Incident response

We maintain an incident-response process with defined roles and communication templates. Confirmed personal-data breaches are notified to affected clients without undue delay and, where GDPR applies, within 72 hours.

Compliance and attestations

• SOC 2: we maintain SOC 2 control mapping in our own controls library, but a formal Type 1/2 attestation is not yet underway. We will publish the engagement status and expected report date here as it progresses, and we will not claim certification before it exists. Ask for our security pack for the current control set.
• ISO 27001: under consideration; not yet in scope.
• GDPR / UK GDPR: we act as a processor under a Data Processing Addendum; see our DPA and sub-processors.

Responsible disclosure

If you believe you’ve found a vulnerability, email security@regspace.ai. Please do not access other tenants’ data or disrupt the Service. We commit to acknowledging within 2 business days and to keeping reporters informed through triage, fix, and coordinated disclosure.