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. This page documents the security program we operate and the program we are building out. We separate what is in place today from what is planned, and we do not claim controls we have not implemented. For a full control set or a completed vendor-security questionnaire, ask for our security pack at hello@regspace.ai.

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, and the API checks that the tenant on the request matches the tenant in the URL on every call, so a mis-scoped query fails to resolve rather than returning another tenant’s rows.
• Tenant-scoped processing.Every scheduled run operates against exactly one tenant’s schema. Prompts and tool results sent to language models are scoped per call to that same tenant, so a model request carries one tenant’s context and only that tenant’s context.
• Database-layer access controls. The request path runs under a constrained database role with no schema-changing or bulk-delete rights, so isolation does not rest on application-layer scoping alone. Per-tenant database roles are a planned next layer.

Encryption

• In transit.TLS 1.2 or higher on all hosts, with HSTS enabled (the marketing site is HSTS preloaded). Internal traffic between our services and the database stays on the cloud provider’s private network.
• At rest.The database is encrypted with AES-256 at the storage layer. Stored tenant documents are encrypted with a per-tenant Customer-Managed Encryption Key (CMEK) held in Google Cloud KMS and enforced at the storage bucket level. The key belongs to the tenant; rotating or destroying it renders that tenant’s stored documents unreadable. See our sub-processors for the underlying providers.
• Secrets. Production secrets, including any per-connector credentials and tenant keys, live in Google Secret Manager with scoped access, resolved at runtime.

Authentication and access

• Single sign-on. SSO via SAML and OIDC, with SCIM user provisioning and de-provisioning, so your identity provider remains the source of truth. This is live today.
• Multi-factor authentication. MFA for your users is enforced by your own identity provider through SSO. MFA is required for regSpace platform-admin accounts: a time-based one-time code (TOTP) from an authenticator app, in addition to Google sign-in, so the platform cannot be administered with a single factor.
• Role-based access. The portal supports role-based access (viewer, contributor, approver, admin). Fields that carry billing or entitlement meaning are protected at the database grant level so they cannot be self-escalated.
• Operator access.Production access is restricted to a small team and is audited. Read-only and bounded write (“act-as”) tenant impersonation for support, together with a signed portal-to-API assertion, are built and being rolled out; these controls ship switched off by default and are not yet enforced in production.
• Bring your own model key.Tenants may supply their own Anthropic or Gemini key, stored in Google Secret Manager, so inference runs under their own account and provider agreement. This is an on-demand governance accommodation with no change to pricing; by default, regSpace’s own provider keys are used.

Model-provider controls

• Language-model inference runs via enterprise endpoints. We do not train or fine-tune on client data.
• Nothing is auto-published. Every monitoring item links to its primary source so your team verifies it directly, a person keeps or deletes each item, and every redline is reviewed before it is applied.
• regSpace outputs are draft regulatory intelligence for legal review. They are not legal advice.

Audit trail

Every material processing action (what was classified and drafted, with the model and version that produced it) and every human keep or delete decision is recorded in a per-tenant hash-chained audit log (record[n].prev_hash = sha256(record[n-1])). The review decisions and risk-history chains use the same primitive. Each chain is independently re-verifiable on demand, so after-the-fact tampering is detectable. Anchoring each chain’s tip to retention-locked storage, which makes a whole-chain rewrite detectable over time, is built but is opt-in and not enabled by default in production.

Backup, business continuity, and disaster recovery

Current. Tenant data sits on managed cloud infrastructure with automated storage-level durability. Application and infrastructure configuration is defined in version-controlled code, so a service can be rebuilt from a known state. Stored tenant documents and the database are recoverable from the underlying provider.

Planned. We are formalising a documented backup and restore schedule with periodic restore tests, and publishing target recovery objectives. The targets we are working toward are a recovery time objective (RTO) of 24 hours and a recovery point objective (RPO) of 24 hours for tenant data. We will state the measured, tested figures here once restore testing is in place, and we will not claim a tested RTO or RPO before it is verified.

Secure development and change management

Current. All changes go through version control with code review before release. Material changes receive a multi-lens review (correctness, security, and data-handling), and automated tests must pass before a change is deployed. Dependencies are pinned to explicit versions across the codebase, and container images are built from pinned base images. Production and non-production paths are separated, and releases are reproducible from source.

Planned. We are standing up continuous integration to run the test and security gates automatically on every change, along with signed commits and signed container images, sequenced with that rollout.

Vulnerability and dependency management

Current. Dependencies are pinned and updated deliberately rather than floating. Security-relevant updates to dependencies and base images are applied through the same reviewed change process. Reported vulnerabilities are triaged and remediated on a risk-based timeline.

Planned. We are adding automated dependency and container-image scanning in the build pipeline, with severity-based remediation targets that we will publish here.

Penetration testing

Planned. We are establishing an independent external penetration test on an annual cadence, plus a focused test after any significant architectural change. A summary letter will be available to customers under NDA once the first engagement completes. We do not claim a completed third-party penetration test today.

Incident response and breach notification

We maintain an incident-response process with defined roles, severity levels, and communication templates. Confirmed personal-data breaches are notified to affected clients without undue delay and, where GDPR or UK GDPR applies, within 72 hours, consistent with our DPA. We are formalising periodic tabletop exercises against this process.

Data retention and deletion

Tenant data is retained for the life of the subscription. On termination, and at your option, we delete or return personal data and delete existing copies, subject to legal retention obligations. Audit records are kept while the tenant is active and retained after offboarding for the period set out in our DPA before hard deletion. The full retention and deletion terms live in the DPA.

Data residency

• Application, database, and documents: regSpace runs as a single London deployment: application compute and stored documents in Google Cloud europe-west2, the database in AWS eu-west-2(managed by Neon). Everything is encrypted at rest, with each tenant’s business data held in its own database schema.
• AI drafting calls:the models that write the digest and the redlines run on the providers’ own regions, which are separate from the hosting region. Claude runs through Google Vertex AI in the EU (europe-west1); Gemini runs on Vertex’s global endpoint, because the model we use is published there; Anthropic’s direct API serves some deployments. The request payload (regulatory text plus policy snippets) is what leaves London for those calls. Each provider, and the transfer safeguards, are named on our sub-processors page.
• The residency region agreed at onboarding is recorded on your tenant record. It is the region a tenant is provisioned into as we add regions; today London is the region we operate. Where a second region, or an EU-pinned inference region, is a condition of your deal, tell us during procurement and we will put the timeline in writing.
• Regulatory coverage spans EU, UK, US (federal and priority states), and Australia; coverage and hosting region are independent.

Compliance and attestations

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

Responsible disclosure and security contact

If you believe you have found a vulnerability, email hello@regspace.aiwith the subject line “Security”. Please do not access other tenants’ data, run automated scans that degrade the Service, or disrupt the Service in any way. We commit to acknowledging within 2 business days and to keeping reporters informed through triage, fix, and coordinated disclosure. We will not pursue good-faith researchers who follow this policy.