ContrayoThe mechanisms behind the claims
Contrayo does not hold a SOC 2 certification today, so we're not showing you a report or a badge. What we can show you is real: the specific mechanisms built into the product today, described plainly enough for your own security team to go verify them.
How your login is protected
Password storage
Passwords are hashed with scrypt, a deliberately memory-hard algorithm, using a unique random salt per password and a constant-time comparison on verification. Your actual password is never stored, logged, or compared in plain text anywhere in the system.
Session tokens
Signing in issues a random 256-bit token. Only its cryptographic hash is ever stored in the database — the raw token exists solely in your browser's cookie, so reading the database itself doesn't hand over anything that still works as a credential.
Cookie hardening
The session cookie is marked HttpOnly (invisible to page scripts, closing off theft via a cross-site scripting bug), SameSite=Lax (a real defense against cross-site request forgery), and Secure whenever served over HTTPS.
HTTP security headers
Every response carries a strict Content-Security-Policy — no inline scripts, no third-party script sources — plus Strict-Transport-Security,X-Frame-Options, X-Content-Type-Options, andReferrer-Policy. Standard browser-level defenses against clickjacking, MIME-sniffing, and script injection, sent on every response, including error pages.
Login throttling
Failed logins are rate-limited both per account and per source IP address, with a temporary lockout after repeated failures. A login attempt against an email with no account takes exactly as long as one against a real account with the wrong password, so timing alone can't be used to discover which emails have accounts.
Session lifecycle
Sessions expire automatically, and specific events revoke them outright: resetting a password, or an admin deactivating an account, immediately signs that account out of every session it holds — not just the one that triggered it.
Password reset
Reset links are single-use and expire after one hour. They're stored the same hashed-not-raw way session tokens are, and the link itself is only ever returned once, directly to whoever requested it — never written to a log.
Multi-factor authentication
Time-based one-time passcodes (TOTP, compatible with any standard authenticator app), email one-time codes, and SMS one-time codes are all live today. TOTP and email are available on every tier; SMS is a Mid-market/Enterprise capability. Any user can turn one on for their own account, and an organization can require MFA for everyone — enforcement is free on every tier, not a paid add-on, matching the majority pattern in this category (GitHub, Slack, GitLab, Zoom, and Salesforce all give it away too). The secret behind each enrollment is encrypted at rest — never stored or logged in the clear — and ten single-use recovery codes are issued at enrollment in case a device is lost.
Login and logout history
Every sign-in attempt, sign-out, and session expiration is recorded with its timestamp, IP address, and browser — a failed attempt is logged too, though never in a way that reveals whether the email itself has an account. Any user can see their own history; an org admin can see it for the whole organization. This log is best-effort, not a substitute for the full audit trail described below — a logging failure never blocks a real sign-in.
Your organization's data stays your organization's
Closed by default
Every API route requires an authenticated session unless it's on a short, explicit public list (signing in, signing out, requesting or confirming a password reset, and reading the current published legal terms). Nothing else is reachable without one.
Tenant isolation, enforced on every request
One organization's data is walled off from every other organization's. A shared, tested check runs on every request that references another record — confirming it not only exists but actually belongs to the caller's own organization — rather than trusting a query's own filter to be enough.
One authorization chokepoint
Every permission decision in the product is decided by a single function, and it fails closed: a permission it doesn't recognize, or a session with no matching grant, is denied by default rather than allowed.
Configurable password policy
Your organization sets its own minimum password length and composition requirements. The exact same check that shows a live checklist to the person setting a password also runs on the server, so what the screen shows can never disagree with what the server actually accepts.
Single sign-on & SCIM provisioning
OIDC single sign-on and SCIM 2.0 user provisioning are available on our Mid-market and Enterprise plans. Sign-in is verified against your identity provider's own signed token and matched to your organization by its email domain; deactivating someone in your identity provider deactivates their account here too.
Test Environments
A real, isolated copy of your organization — its contract types, statuses, hierarchies, clause library, and full policy history — for trying a policy change or a bulk import without touching production. Contract data inside it is synthetic, generated from your production data's aggregate statistics, never a copy of real contracts, counterparties, or values. Mid-market and Enterprise only, and only an org admin can provision, reset, or sync one.
A hard stop on external AI processing, when your DPA requires it
If your organization's negotiated Data Processing Addendum prohibits sending your content to an external AI processor, we set that restriction ourselves — it isn't a toggle your own admins configure. Once set, it's enforced at the single point every AI capability in the product has to pass through, ahead of any per-feature setting, and every AI capability in your admin console shows as disabled with a plain explanation of why.
Controls that come from the product itself, not a bolt-on
Segregation of duties
When your organization turns the setting on, the delegation-of-authority engine enforces it directly: the same person who approved a contract can't also be the one who signs it.
Full approval history
Every approve, reject, and sign decision on a contract is recorded — who acted, when, and, if they acted through a delegation on someone else's behalf, who they were standing in for — visible in that contract's own history.
Full platform audit trail
Beyond the approval history above, every action across the product — not just contract approvals — is recorded to a separate, immutable, hash-chained audit trail, live in our production environment today. Altering an earlier entry breaks the chain from that point forward, so tampering doesn't go unnoticed.
Admin accountability
Deactivating a member's account immediately revokes every session they hold, and an organization can never be left with zero administrators able to manage it — the app blocks any change that would leave one with none.
Encryption in transit
Requests to Contrayo travel over HTTPS/TLS, standard practice for any properly deployed web application today.
An anonymous channel for reporting concerns
Anyone — staff, contractors, customers, or vendors — canreport a suspected violation of our Code of Business Conductanonymously. The form collects no name, email address, or other identifying information, and retaliation against a good-faith report is prohibited.
What we don't have yet
Named directly rather than left for you to discover during a security review:
- No SOC 2 certification exists today.
- No independent penetration test has been completed yet. An external, authenticated test has been commissioned. We also run our own internal, automated attack suite against the product — session and login attacks, cross-tenant data isolation, privilege escalation, injection, forged-identity attempts, and more — as a standing part of our own development process. That's real testing, but it's internal and self-run, not a substitute for an independent third-party assessment.
If any of these are a hard requirement for your organization today, we'd rather tell you now than have you find out during procurement.
Security questions a questionnaire needs answered?
Get in touch and we'll answer directly — no sales call required to get a straight answer.
Get in touch