Trust center

Security at ContractShield

Contracts contain some of the most sensitive information your organization handles. Pricing, obligations, intellectual property, personal data, commercial terms. We built ContractShield with that reality in mind from day one.

This page explains how we protect your data, what certifications back our infrastructure, and what controls you inherit when you use ContractShield.

Request security documentssecurity.txt
  • AES-256-GCM at rest, fail-closed
  • TLS 1.2+ in transit, HSTS
  • Email-code + TOTP MFA
  • SOC 2-mapped audit trail
  • Tenant isolation on every query
  • Daily backups + point-in-time recovery
  • No AI training on your data
  • DigitalOcean SOC 2 Type II hosting

Your data is yours

We do not train AI models on your contracts. We do not sell or share your data. Contract content sent to our AI provider (Anthropic) is excluded from their model training under standard API terms. ContractShield uses your data for one purpose only: delivering the service to you.

No model training on your data

Contract content sent to our AI provider is excluded from their model training under standard API terms. Your contracts never become training data.

No data sale or sharing

We do not sell your data and we do not share it with third parties for advertising, analytics, or any purpose unrelated to delivering the service.

Single-purpose use

ContractShield uses your data for one purpose only: delivering the service to you. Every internal control is designed around that boundary.

Engineering

How we engineered it

Certifications describe outcomes; these are the mechanisms. Each item below is a control implemented in the ContractShield codebase or hosting stack, stated the way we answer it on security questionnaires.

Fail-closed file encryption

Uploaded contracts are encrypted with AES-256-GCM before they touch disk. The design is fail-closed: if encryption cannot complete for any reason, the upload is rejected — a document is stored encrypted or not at all. Sensitive database fields (MFA seeds, provider credentials) are encrypted with the same scheme.

MFA done properly

Two second-factor options: one-time codes emailed at sign-in (hashed, single-use, 10-minute expiry, attempt-capped) and TOTP authenticator apps (RFC 6238, compatible with Google Authenticator, Authy, and 1Password). TOTP seeds are encrypted at rest, backup codes are single-use and stored only as bcrypt hashes, code verification is constant-time, and the login handoff uses a separate, short-lived, MFA-scoped token that cannot access the API.

No public file paths — ever

Uploaded documents, redlines, and signed PDFs are never served as static files. Every file request passes through an authenticated route that enforces your organization boundary before a single byte is streamed.

Audit logging mapped to SOC 2

The audit subsystem is designed around SOC 2 Common Criteria CC6.1 and CC7.2: every material action records the actor, timestamp, action type, affected record, IP address, and user agent — including administrative impersonation, so even our own support access leaves a trail you can inspect.

Boot-time secrets guard

The production server refuses to start with missing or placeholder signing keys or encryption keys. Misconfiguration fails loudly at deploy time — before it can ever touch customer data.

Hardened session model

Passwords are hashed with bcrypt at cost factor 12. Sessions use short-lived access tokens (15 minutes) backed by bounded refresh tokens that are revalidated against account status on every renewal. Chat and auth endpoints carry their own rate limits on top of the platform-wide limiter.

Sessions that actually end

Sessions are terminated after 15 minutes of inactivity by default, and after 12 hours regardless of activity — enforced on the server on every request, not by a timer in your browser that a sleeping laptop can pause. Administrators can set their own organization's inactivity window, from 15 minutes to 24 hours, to match their internal policy; the hard limit from sign-in moves with it so the setting means what it says. Signing out, changing a password, and suspending or off-boarding a user all revoke live sessions immediately, on every device.

Signature-verified billing webhooks

Payment webhooks are cryptographically signature-verified and idempotent; unsigned or replayed events are refused in production. Billing state cannot be forged from the outside.

Governed AI spend

Every AI call is logged with token counts and estimated cost, subject to per-organization monthly spend caps and platform-level kill switches. A runaway integration cannot silently consume your data or our budget.

Infrastructure and hosting

ContractShield runs on DigitalOcean, a cloud provider that maintains SOC 2 Type II and SOC 3 Type II certifications under AICPA attestation standards. DigitalOcean also holds Cloud Security Alliance STAR Level 1 certification and is GDPR compliant with a standard Data Processing Agreement.

You can review DigitalOcean’s current certification reports at their public Trust Platform: digitalocean.com/trust/certification-reports(opens in a new tab).

Our application and database infrastructure is hosted in DigitalOcean’s US data center regions with redundant availability zones. We follow DigitalOcean’s managed patching for the database layer and apply continuous dependency scanning and expedited vulnerability patching at the application layer.

Encryption

All data in transit between your browser, our application, and any integrated services is encrypted using TLS 1.2 or higher. We enforce HTTPS across the entire platform, with HSTS instructing browsers to never downgrade.

All data at rest is encrypted using AES-256. This includes:

  • Uploaded contracts, redlined documents, and signed agreements — encrypted file-by-file with AES-256-GCM before they reach storage, fail-closed
  • Your PostgreSQL database, including all contract metadata, user records, and audit logs
  • Sensitive application fields such as MFA seeds and integration credentials, individually encrypted at the application layer
  • Database backups and point-in-time recovery snapshots

Authentication and MFA

Passwords are stored only as salted bcrypt hashes (cost factor 12) — we never see or store your plain-text password. Multi-factor authentication is available for every account, with a choice of one-time codes sent to your verified email or a TOTP authenticator app (Google Authenticator, Authy, 1Password, and similar apps). MFA seeds are encrypted at rest, backup codes are single-use and stored as hashes, and verification uses constant-time comparison to resist timing attacks.

Backups and recovery

Your data is backed up automatically every day through DigitalOcean’s managed PostgreSQL service. Point-in-time recovery is available, allowing restoration to any moment within the retention window. Backup integrity is verified on a regular schedule.

File storage in DigitalOcean Spaces maintains redundant copies across multiple physical locations within the region, protecting against hardware failure.

Access controls

ContractShield uses role-based access control (RBAC) at the application layer. Every user action is governed by the permissions assigned to their role within your organization.

Multi-level approval workflows let you configure who can approve contracts at each risk threshold. Sensitive actions, such as executing agreements above specified thresholds or modifying system-wide risk posture, can require multiple approvers.

Uploaded files are never exposed as public static paths. Every document download passes through an authenticated route that enforces your organization boundary before any content is served.

Audit trails

Every material action in ContractShield is logged to an immutable audit trail: contract uploads, edits, redlines, approvals, signatures, downloads, user permission changes, and configuration updates. Audit logs include the actor, timestamp, action type, affected record, and IP address. The logging design is mapped to SOC 2 Common Criteria CC6.1 and CC7.2, and captures administrative access as well — support impersonation, when it occurs, is itself audited. Logs are retained for the duration of your subscription and are exportable for your own compliance needs.

Tenant isolation

Customer data is logically isolated. Each customer account operates within its own access boundary, and our application enforces tenant separation on every database query and file retrieval. No ContractShield customer can access another customer’s data.

For Enterprise customers, we offer a dedicated single-tenant database option. In this configuration, your organization’s data resides in a physically separate database instance rather than a shared logical tenant. This is available as part of Enterprise plans on request.

Application security

  • Dependency scanning. All third-party code libraries are scanned continuously for known vulnerabilities. Critical vulnerabilities are patched on an expedited timeline.
  • Code review. All changes to the ContractShield codebase go through peer code review before merging to production.
  • Secrets management. API keys, database credentials, and integration tokens are stored in encrypted secret stores and never committed to source control. We use GitHub’s push protection to prevent accidental credential exposure, and the production server refuses to boot with missing or placeholder secrets.
  • Least privilege. Internal access to production systems is restricted to the minimum personnel required for operations, with access reviewed regularly.
  • Rate limiting. Platform-wide request limits with tighter per-endpoint budgets on authentication and AI endpoints.

AI and data handling

ContractShield uses Anthropic’s Claude API — specifically Claude Opus 5 — to power contract analysis, risk scoring, redlining, and AI drafting. Under Anthropic’s API terms, your contract content sent to Claude is not used to train Anthropic’s models. Data transmitted to the API is encrypted in transit and handled under Anthropic’s own security controls, including SOC 2 Type II certification.

Every AI call is additionally logged and metered on our side, with per-organization spend caps and platform-level kill switches — governance for the AI layer, not just the data layer.

Integrations

ContractShield integrates with Docusign for e-signature workflows through Docusign’s official webhook and API interfaces. Billing runs on Stripe with signature-verified, idempotent webhooks — unsigned events are refused in production. All integration traffic is authenticated and encrypted. Other integrations (CRM, document management, and similar) are on our roadmap and will follow the same security standards.

Compliance roadmap

ContractShield is actively working toward its own SOC 2 Type II certification, and the controls described on this page — SOC 2-mapped audit logging, least-privilege access, fail-closed encryption — are being built and operated with that audit in mind. We will publish our report on this page once the audit is complete. Until then, we’d rather show you exactly what we’ve built than borrow a badge.

For customers with specific regulatory requirements (HIPAA, GDPR data residency, FedRAMP, and similar), please contact us directly to discuss your needs.

Responsible disclosure

If you believe you have discovered a security vulnerability in ContractShield, please email [email protected] with details. We commit to acknowledging reports within two business days and working in good faith to investigate and resolve valid issues. We do not pursue legal action against researchers who follow responsible disclosure practices. Our security.txt is published at the standard location.

Documents available on request

  • ContractShield Data Processing Agreement (DPA)
  • DigitalOcean SOC 3 Type II Report (public, linked above)
  • Security questionnaire responses (SIG Lite, CAIQ)
  • Subprocessor list

Request security documents

Last updated: July 5, 2026

Evaluate it on your own paper.

30-day free trial, no credit card. Your uploads are encrypted before they touch disk.

Start free trialRequest a demo