Security white paper

This white paper is written for information-security reviewers evaluating clmSpace, operated by Rated Counsel Limited(United Kingdom). clmSpace sits in the document layer of legal teams in regulated sectors, so we treat confidentiality, integrity and tenant isolation as primary design constraints and defend in depth. The sections below describe our controls at a level reviewers can assess. A fuller security pack, including our policies, sub-processor due-diligence records and the underlying platforms’ attestations, is available on request (see Compliance and assurance).

Architecture and data residency

clmSpace is a hosted service. The backend API runs on Microsoft Azure Container Apps in the United Kingdom, and derived contract intelligence is held in a tenant-scoped data store in the United Kingdom.

• Source documents stay with the customer.Source contracts, templates and drafts (PDF and DOCX) remain in the customer’s own SharePoint or Google Drive. clmSpace reads them through connectors (Microsoft Graph for SharePoint, the Google Drive API) using permissions the customer grants and controls, and keeps no separate copy of the source files.
• Derived structured data in the United Kingdom. Structured contract data (agreements, obligations, citations and lifecycle records) is held in Neon Postgres (AWS London, United Kingdom), scoped to the customer’s tenant, and serves obligation lists, dashboards and counterparty views at low latency.
• Customer portal. The customer portal is hosted on Vercel (London region). The public marketing site is a separate project that processes no customer contract data.
• AI inference. Extraction, analysis and review use Anthropic Claude (Sonnet class), processed in the United States under contractual data-protection terms described below.

Identity and access

• Single sign-on through the customer’s identity provider.End users authenticate with Microsoft Entra ID (Azure AD) single sign-on, including Microsoft Teams single sign-on. The customer’s own identity boundary and conditional-access policy (multi-factor authentication, device compliance, named locations) therefore govern who can sign in.
• Platform-issued sessions. After sign-in, clmSpace issues its own signed, HTTP-only, Secure session scoped to the tenant and the user, with a short default lifetime. Approved integration clients, such as the Microsoft Copilot connector, authenticate with a separate bearer scheme rather than reusing user sessions.
• Least privilege and role separation. Authorisation distinguishes administrator and verifier roles and keeps a separate platform-owner scope away from tenant data. Administrative actions (configuration, bindings, standards and clause changes) require the caller to hold the relevant role, re-checked on every request.
• Agreement-level access control. Sensitive agreements enforce access at the individual-agreement level, combining role and group permissions with attribute-based rules. Restricted agreements are deny-by-default and are invisible to a user without an explicit grant. All authorisation checks fail closed.
• Operator access is governed. Multi-factor authentication is mandatory for all clmSpace staff accounts. Production access is limited, time-bound, peer-approved and recorded in platform activity logs.

Multi-tenant isolation

• Every request is bound to a verified tenant. The active tenant is resolved from the authenticated session or approved integration credential and carried through the request; downstream calls to storage, document connectors and inference inherit that scope. There is no shared ambient tenant state.
• Isolation extends to caches and the read model.The read model and any caches are tenant-scoped, so a query for one tenant cannot surface another tenant’s data.
• Enforced on every read and write.Tenant scoping is applied to list operations and to single-record lookups alike, so a mis-scoped request fails closed rather than returning another tenant’s data.
• Human verification as a control surface.AI-derived obligations and standards become authoritative only after a human verifier confirms or overrides them, giving a single auditable checkpoint between extraction and the customer’s house view.

Encryption

• Customer traffic is protected with TLS in transit.
• Data is encrypted at rest across the managed services we use, namely Azure and Neon, using each platform’s managed-key encryption.
• Application secrets are delivered as managed platform secrets rather than embedded in container images, and are rotated under change control.

Secure development and testing assurance

• Automated test coverage of security controls. Authentication, authorisation, tenant isolation and agreement-level access control are exercised by an automated test suite of more than 160 tests. The suite gates deployment, so a change that weakens these controls is caught before it reaches production.
• Change control. Changes move through version control and continuous integration before release. Continuous integration authenticates to cloud resources using short-lived federated credentials rather than long-lived secrets.
• Integrity of releases. Production images are built from pinned bases and deployed as immutable, digest-pinned revisions, so each running version is identifiable and reproducible and rollback is deterministic.

Dependency and vulnerability management

• Third-party dependencies are pinned and scanned, with automated security updates raised across our repositories so known-vulnerable components are surfaced and remediated promptly.
• Container images are built from a pinned, maintained base, scanned, and locked to a digest per revision.
• We operate a responsible-disclosure channel (below) and triage reported issues on a defined timeline.

Logging and monitoring

• Verification and override actions are auditable. When a verifier confirms or overrides an AI-derived obligation, the platform records the acting user, a timestamp, the before and after values and the stated reason, giving a reviewable history of how the authoritative view was reached.
• Lifecycle events are recorded. Material lifecycle events on an agreement are captured with the timestamp and the user or process that triggered them.
• Inbound callbacks are verified. Webhook callbacks are authenticated with HMAC verification, and secret comparisons use constant-time checks to resist timing attacks.
• Platform observability. Runtime activity and deployments are captured in cloud platform logs available to our operations team for monitoring and investigation.

Incident response

We maintain a written incident-response plan covering roles, escalation, forensic steps and communications. Confirmed personal-data breaches are notified to affected customers without undue delay and, in any event, within 72 hours, consistent with UK GDPR Article 33. Customers can report suspected security issues through the responsible-disclosure channel below, and we acknowledge reports promptly and keep reporters informed through triage, fix and coordinated disclosure.

Business continuity and disaster recovery

Our continuity posture is built on managed cloud platforms that provide durable, replicated storage and regional resilience as standard.

• Source documents stay in the customer’s own SharePoint or Google Drive, which benefit from those platforms’ redundancy and recovery capabilities.
• Derived structured data is held in a managed Postgres service with durable, replicated storage, and derived views can be rebuilt from the authoritative records, so recovery does not depend on a single store.
• Releases are deployed as immutable, digest-pinned revisions, allowing a known-good version to be restored quickly.

Data handling and retention

• Roles.Under the GDPR the customer is the controller and Rated Counsel Limited is the processor, acting on the customer’s documented instructions under the Data Processing Agreement.
• Source minimisation.clmSpace reads source documents from the customer’s SharePoint or Google Drive and keeps no separate copy of them; derived structured data is held in the service’s tenant-scoped UK data store.
• AI data handling.Inference uses Anthropic Claude (Sonnet class). Under Anthropic’s API terms and our commercial agreement, API data is not used to train models; Anthropic retains API data for up to 30 days for abuse monitoring. AI output is treated as draft contract intelligence for professional review, with low-confidence items flagged, and an obligation is relied upon only after a human verifier confirms or overrides it.
• Retention and deletion. We commit to deleting client content within 30 days of termination on request; operational logs are retained for approximately 90 days. Deletion is available on request and through administrative tools.

Sub-processor governance

We maintain a complete, current register of the sub-processors that process customer contract data, with each one’s role and processing location, in our sub-processor register. New or replacement sub-processors are subject to due diligence and to the change-notification commitments in the Data Processing Agreement. The register covers Microsoft (Azure hosting and document OCR), Neon (structured contract data), Vercel (portal hosting), Anthropic (AI inference) and DocuSign (optional, per-tenant e-signature). Transfers to Anthropic in the United States are covered by the UK International Data Transfer Agreement referencing the EU Standard Contractual Clauses.

Compliance and assurance

• Inherited platform attestations. clmSpace builds on providers that hold their own independent attestations, including Microsoft Azure (ISO 27001, SOC 2 Type 2, ISO 27017 and ISO 27018) and Anthropic (SOC 2 Type 2). Customers can request the underlying attestations from each provider.
• clmSpace certification roadmap. We are pursuing SOC 2 Type 1 with a 2026 target, followed by ISO 27001. Our control framework, including the access, isolation, encryption and testing controls described here, is being operated to that standard now.
• Request the security pack. Reviewers can request our security pack, covering policies, sub-processor due-diligence records and the underlying platform attestations, at security@clmspace.com.

Responsible disclosure

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