Security and SSO

Data residency, single sign-on, MFA, audit logs, and how Clment handles your contracts.

Updated 28 Sept 2026

Contracts are sensitive. This page covers how Clment handles your data, the auth options available, and where to look for an audit trail.

Data residency

Clment runs as a set of regional planes. Each region keeps its stored data physically within that region — contracts uploaded into a US org are stored within the US region and stay there at rest. The one exception is while an AI review is actually running: the analysis may run on AI models hosted outside your region, using temporary copies that are deleted shortly afterwards and are never used to train the models. Available regions:

  • US — Azure East US 2.
  • EU — Azure Germany West Central (Frankfurt). AI inference for this region runs in Sweden Central, so both storage and processing stay inside the EU.
  • UK — Azure UK South (London).
  • AU — Azure Australia East (Sydney).
  • NZ — Azure New Zealand North (Auckland), for in-country residency.
  • CA — Azure Canada Central (Toronto).

Backups are geo-redundant to a paired Azure region in the same country — Canada Central to Canada East, UK South to UK West, Australia East to Australia Southeast — so a backup never leaves the jurisdiction you picked. New Zealand is the exception: Azure has no second New Zealand region, so NZ backups are zone-redundant within New Zealand North, plus an offsite copy held with a New Zealand provider rather than shipped abroad.

Cross-region work — like a multi-region admin viewing usage stats — happens via aggregated metadata only; the underlying contract data stays in-region.

Single sign-on (SSO)

Clment has two single sign-on providers built in. Both use Clment’s own applications, so there’s nothing to register with your identity provider and nothing to send us:

Each person connects their own account: by signing up or accepting an invitation with Microsoft or Google, or with Connect on Settings → Security. A provider account with the same email as their Clment account connects straight away; one with a different email is connected only after they confirm it from a link we email to their Clment address.

Signed up with Microsoft or Google and want to be able to sign in with a password too? On Settings → Security, the Email and password row offers email me a link to set one — you choose the password on Clment’s sign-in site, and stay signed in where you are. Once you have a password, we’ll suggest turning on two-factor authentication for it.

Admins decide which sign-in methods the organisation accepts, from the Sign-in methods card on Settings → Security:

  • Require for org on a provider’s row — everyone must sign in with that provider.
  • Disable for organization on the password row — password sign-in is off; Microsoft and Google are both accepted. (Disable password for organization, if you’re an SSO-only admin.)

Clment then refuses the other methods at sign-in. Members who haven’t connected the required provider yet are connected automatically on their first sign-in with it, as long as the provider’s verified email exactly matches their Clment email.

Signing in with Microsoft or Google doesn’t grant access to your organisation on its own: your members are the people you invite from Settings → Team, and the invitation’s email must match what the provider returns.

Multi-factor authentication

For non-SSO sign-in, MFA is optional on Free and enforceable org-wide on paid plans. Clment supports authenticator apps (Google Authenticator, Authy, 1Password, etc.) plus backup codes.

Org admins can require MFA org-wide from the Sign-in methods card on Settings → Security — Require 2FA for organization. Existing users without MFA are walked through enrollment on their next sign-in.

Sign-ins with Microsoft or Google are exempt — the provider’s own MFA policy applies. Forcing a second factor on top of an identity provider’s existing MFA is redundant. (Someone who can sign in both ways still needs 2FA set up for their password sign-ins.)

See MFA and account protection for the user-side walkthrough.

Encryption

  • At rest: Azure Storage Service Encryption is on by default for all storage.
  • In transit: TLS 1.3 (TLS 1.2 minimum). HSTS enabled on every public hostname.
  • Backups: encrypted with the same keys as the live data; retained 90 days.

Audit log

Every state-changing action against a contract or review writes an audit row. You can see the per-contract trail under the contract’s Activity tab. The trail includes the user, the action, the resource id, and the timestamp.

For SOC 2 / compliance evidence, contact support — we can produce an organisation-wide export covering whatever window you need.

Reporting a security issue

If you’ve found a vulnerability, please report it via our security page, which lists the disclosure contact and PGP key. We respond within 24 hours and follow coordinated-disclosure norms.

See also

Still have questions?

Instant article search