Technical and organisational measures (TOMs)

This schedule sets out the technical and organisational measures that Rated Counsel Limited (t/a clmSpace) maintains to protect personal data processed through the clmSpace platform (the "Service"). It is the schedule of technical and organisational measures referenced in our data processing addendum, written so that an information-security reviewer can assess our controls. Each measure below describes a control that is present today. A fuller security narrative is set out in our security white paper.

1. Access control and identity

• Single sign-on.End users authenticate with Microsoft Entra ID single sign-on, including Microsoft Teams single sign-on, so the customer’s own identity boundary and conditional-access policy 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.
• Least-privilege roles. Authorisation distinguishes administrator and verifier roles and keeps a separate platform-owner scope away from tenant data. Administrative actions 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.

2. 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, so downstream calls to storage and inference inherit that scope. There is no shared ambient tenant state.
• Tenant-scoped caches and 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.

3. 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.
• Sensitive tenant credentials are additionally envelope-encrypted at the application layer, so they are protected beyond the platform’s own at-rest encryption.

4. Secret management

• Application secrets are delivered as managed platform secrets rather than embedded in container images, and are rotated under change control.
• Continuous integration authenticates to cloud resources using short-lived federated credentials rather than long-lived secrets.

5. Auditability

• Verification and override actions are recorded. 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.
• Inbound callbacks are verified. Webhook callbacks are authenticated with HMAC verification, and secret comparisons use constant-time checks to resist timing attacks.

6. Software assurance and secure development

• 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.
• Secure software development lifecycle. Changes move through version control and continuous integration before release. Production images are built from pinned bases and deployed as immutable, digest-pinned revisions, so each running version is identifiable and reproducible.
• 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.

7. Logging and monitoring

• Material lifecycle events on an agreement are captured with the timestamp and the user or process that triggered them.
• Runtime activity and deployments are captured in cloud platform logs available to our operations team for monitoring and investigation.

8. 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 our responsible-disclosure channel, and we acknowledge reports promptly and keep reporters informed through triage, fix and coordinated disclosure.

9. Business continuity and backup

• 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.

10. Data handling and retention

• 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 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.
• We commit to deleting client content within 30 days of termination on request; operational logs are retained for approximately 90 days. The full schedule is set out in our data retention schedule.

11. Personnel measures

• Personnel authorised to process personal data are bound by a duty of confidentiality and are granted access on a least-privilege, need-to-know basis.
• Multi-factor authentication is mandatory for all clmSpace staff accounts. Production access is limited, time-bound, peer-approved and recorded in platform activity logs.

Contact

Reviewers can request our fuller security pack, covering policies, sub-processor due-diligence records and the underlying platform attestations, at security@clmspace.com.