C
ComplyWise
Start free trial

Legal

Security at ComplyWise

Last updated 2026-09-05

Template notice — read before use. This Security Whitepaper is a starting-point template generated to help ComplyWise, Inc. accelerate its go-to-market and trust-page publication. It is not legal advice and is not a warranty, certification, or contractual commitment. Statements about security controls, compliance posture, and roadmap items must be verified against the as-deployed environment and reviewed and adapted by qualified legal, security, and regulatory counsel before this document is published, shared with prospects, or relied upon. Replace every bracketed placeholder (for example [Governing law: e.g., State of Delaware, USA], [registered address], [DPO / privacy contact email]) with confirmed values, and remove any control described here that is not actually in production.

ComplyWise Security & Trust Overview

ComplyWise is a multi-tenant SaaS learning management system (LMS) built for compliance and GxP training in regulated pharmaceutical and life-sciences organizations. It manages role-based training assignments, SCORM courses, quizzes, 21 CFR Part 11 electronic signatures, PDF/A completion certificates, and a tamper-evident audit trail. Because our customers operate under regulatory scrutiny, security and data integrity are treated as first-class product requirements rather than afterthoughts.

This document describes how ComplyWise protects customer and end-user data: where it runs, how tenants are isolated, how data is encrypted, how access is controlled, and how we maintain the audit integrity that regulated training records demand. It also states our compliance posture honestly — including which independent attestations are on our roadmap rather than already held.

Document owner: ComplyWise, Inc. Security. Last reviewed: [insert date — e.g., 2026-07-11]. Version: [e.g., 1.0 draft].

Infrastructure & hosting

ComplyWise runs on Vercel (application hosting) and Supabase (managed PostgreSQL database and object storage). We do not operate our own servers or data centres. We do not currently offer customer-selected hosting or data-residency regions. Application hosting runs in Vercel’s iad1 region (Washington, D.C., USA); the Supabase project — database and object storage — is in us-east-1 (N. Virginia, USA). Vercel’s global edge network serves static assets from locations worldwide, but the application functions that process personal data execute in iad1.

  • Compute. The application is deployed to Vercel and executes as managed serverless functions distributed across Vercel’s edge network. There are no long-lived hosts or guest operating systems under our administration to patch; runtime and platform maintenance is performed by Vercel as part of its managed service.
  • Database. Application data is stored in a managed PostgreSQL database hosted by Supabase, reached over TLS through a connection pooler. Encryption at rest is provided by Supabase under its platform-level controls. [Confirm the encryption-at-rest configuration on your Supabase project.]
  • Object storage. Uploaded files and generated artifacts (for example course packages and certificates) are stored in Supabase Storage through its S3-compatible endpoint, in a private bucket. [Confirm the bucket’s public-access and server-side-encryption settings.]
  • Cache. ComplyWise uses no separate cache or Redis service. State that must be shared across serverless invocations — principally rate-limit counters — is held in the application’s own PostgreSQL database. The in-process limiter is refused at boot in production, precisely because it would not share state across invocations and would silently weaken brute-force protection.
  • Transactional email. Notifications and system email are delivered through Resend.
  • Error monitoring. No third-party error-monitoring or application-performance-monitoring service is currently enabled. Diagnostics come from our own application logs and from the hosting platform’s request and function logs. If we enable such a service, it will be added to our sub-processor list before it begins processing customer data.

Network exposure. Because the application runs as managed serverless functions rather than on servers we operate, there is no customer-facing virtual private cloud, bastion host, or administrative network under our control to segment. The database is not published to the public internet by ComplyWise: the application reaches it over TLS as a non-superuser role, and network-level restrictions are administered through the database provider’s own controls. [Confirm the network-restriction settings on your Supabase project.]

Tenant isolation

ComplyWise is multi-tenant: multiple customer organizations share the same application and database while their data remains logically separated. We enforce that separation at the database layer, not merely in application code.

  • PostgreSQL row-level security (RLS). Tenant-scoped tables carry RLS policies that filter every query by the active tenant identifier. Even if an application-layer check were missed, the database itself will not return another tenant's rows.
  • Non-superuser application role. The application connects using a dedicated, non-superuser PostgreSQL role that is subject to RLS. Privileged operations (migrations and seeding) use a separate administrative role that the running application does not use. This means a bug in application logic cannot escalate to bypass tenant isolation.
  • Per-request tenant context. The tenant identifier is derived from the authenticated session and applied to the database session for the duration of the request, so RLS policies evaluate against the correct tenant on every read and write.

Defense in depth here means tenant isolation is enforced in two independent layers — application authorization and database RLS — so a single mistake does not become a cross-tenant data exposure.

Encryption

In transit

All connections to ComplyWise are protected with TLS. TLS is terminated at the hosting platform’s edge, and the application’s connection to the database is likewise encrypted in transit. Session cookies are marked httpOnly and Secure so they are not exposed to client-side scripts and are only transmitted over encrypted connections.

At rest

Data at rest is encrypted across the stack: the RDS PostgreSQL database, S3 object storage (SSE), and supporting backups and snapshots are all encrypted. Application-level secrets that are especially sensitive receive an additional layer of protection described under Application Security below.

Authentication & access control

  • Multi-factor authentication (MFA). Users can enroll TOTP-based MFA (compatible with standard authenticator apps) together with single-use backup codes for account recovery. Backup codes can be regenerated by the user after re-verifying their password and a current TOTP code.
  • Single sign-on (SSO). Enterprise SSO via SAML, with SCIM provisioning, is available on the Pro tier and configured per tenant. When SSO is enabled, users authenticate through the customer's identity provider, and matching users can be just-in-time provisioned as learners.
  • Role-based access control (RBAC). Access is governed by clearly separated roles — tenant administrator, author, manager, and learner — plus a manager hierarchy for team-scoped visibility. Users see and can act only within the scope their role grants.
  • Session handling. Sessions use stateless, signed JWTs stored in httpOnly cookies. Sessions enforce an idle timeout; after the configured period of inactivity a user is signed out and must re-authenticate. Active sessions are re-issued on activity without excessive cookie churn.
  • Password policy. Passwords are hashed with bcrypt. Administrators can configure complexity requirements, password history (to prevent reuse), and a password-expiry interval that prompts a mandatory change at next login.
  • Rate limiting & account lockout. Sensitive endpoints (such as login, SSO initiation, and evidence export) are rate-limited on a per-tenant and per-user basis. Repeated failed login attempts within a short window trigger a temporary account lockout; administrators can unlock accounts and review the associated audit events.

Application security

  • Input validation. Requests are validated against strict schemas at the server boundary before any business logic runs, reducing the risk of malformed or malicious input reaching data or downstream systems.
  • Least-privilege IAM. Access to the hosting, database, and storage platforms follows least-privilege principles, and administrative capabilities are separated from the credentials the running application holds. Database roles are scoped the same way: the application connects as a non-superuser role, while migrations and seeding use a separate administrative role (see Tenant isolation).
  • Secrets management & envelope encryption. Highly sensitive stored secrets — including per-user MFA secrets and per-tenant SSO client secrets — are protected with envelope encryption (AES-256-GCM) using a master key held outside the primary datastore. Encrypted values are stored in a versioned, self-describing format so that keys and formats can be rotated over time.
  • Two-person controls. For controlled content workflows, the author or submitter of a course cannot also approve it; publishing requires a separate reviewer's electronic signature. This separation of duties is enforced by the application, not left to policy alone.

Audit & data integrity

Regulated training records are only as trustworthy as the evidence behind them. ComplyWise is built to make that evidence tamper-evident and defensible.

  • Hash-chained audit trail. Security- and record-relevant events are written to an append-only audit log in which each entry is cryptographically linked to the previous one. Any attempt to alter, delete, or reorder historical entries breaks the chain and is detectable by verification. Timestamps used in the hash are pinned to the recorded values so verification is deterministic.
  • 21 CFR Part 11 electronic signatures. Electronic signatures bind the signer's identity, the meaning of the signature, and the specific record and timestamp being signed. Signing requires re-authentication (password re-prompt), and signatures are linked to their records so they cannot be transplanted or repudiated.
  • Evidence packages. Administrators can export a signed evidence package (training records and audit log with a signed manifest) to support inspections and internal audits, with the manifest bound by a cryptographic hash.

Availability & resilience

  • Multi-AZ database. Production RDS for PostgreSQL is deployed in a Multi-AZ configuration so that a failure in one availability zone can fail over to a standby without data loss of committed transactions.
  • Autoscaling compute. The application runs as managed serverless functions, which the hosting platform scales horizontally to absorb changes in demand; failed invocations do not leave a degraded instance in rotation.
  • Backups & point-in-time recovery. Automated encrypted backups and RDS point-in-time recovery (PITR) allow restoration to a chosen moment within the configured retention window. Restore procedures should be periodically tested; recovery objectives (RTO/RPO) are defined operationally — [confirm target RTO/RPO values].
  • Health checks. Liveness and readiness endpoints allow the platform to detect and route around unhealthy instances.

Data lifecycle: export & deletion

  • Data export. Customers retain ownership of their data. Administrators can export training records, audit logs, and completion certificates, and programmatic access is available through the versioned REST API using scoped, per-tenant API tokens.
  • Deletion & offboarding. On contract termination or upon a documented request, customer data is deleted or returned according to the terms of the applicable agreement and Data Processing Agreement. Note that certain regulated records (for example signed training completions and audit entries) may be subject to retention requirements; deletion practices should reconcile customer privacy requests with those regulatory-retention obligations. [Confirm retention and deletion timelines in the DPA.]
  • Privacy requests. We support customers in meeting data-subject requests under GDPR / UK-GDPR where applicable. Direct privacy inquiries to [DPO / privacy contact email].

Vulnerability management & responsible disclosure

  • Dependency and platform hygiene. We monitor dependencies and platform components for known vulnerabilities and apply updates on a risk-prioritized basis. The managed platforms we build on — hosting, database, and object storage — receive underlying host and infrastructure patching from their respective providers.
  • Change controls. Changes flow through version control and continuous-integration checks (including build and type-safety gates) before release.
  • Responsible disclosure. We welcome reports from security researchers. Please report suspected vulnerabilities to [security@complywise.com — placeholder]. Give us reasonable time to investigate and remediate before public disclosure, and do not access, modify, or exfiltrate data belonging to other customers while testing. We will acknowledge legitimate reports and keep reporters informed of remediation status. [Confirm disclosure policy, safe-harbor language, and any bug-bounty scope with counsel.]

Compliance posture

ComplyWise is engineered to help customers meet their obligations under the standards that govern regulated training records. We describe our posture precisely, and we distinguish product capabilities we have built from independent attestations we have not yet obtained.

Standards our platform is designed to support

  • 21 CFR Part 11 — electronic records and electronic signatures: identity-bound e-signatures, re-authentication at signing, and a tamper-evident audit trail.
  • EU Annex 11 — computerised systems: access controls, audit trails, data integrity, and availability practices aligned to the annex's expectations.
  • ICH Q9 — a quality-risk-management mindset applied to how training and controlled-content workflows are designed and enforced.
  • GAMP 5 — a risk-based, lifecycle approach to computerized-system validation; ComplyWise is built to be validatable by customers within their own quality systems.
  • SCORM 1.2 / 2004 — standards-based course interoperability.
  • GDPR / UK-GDPR — privacy-by-design practices for personal data handling, supported by a Data Processing Agreement.

Being "designed to support" these standards means ComplyWise provides the technical controls a customer needs; it does not, by itself, validate the customer's specific implementation. Formal computerized-system validation for an intended use remains a shared responsibility between ComplyWise and the customer.

Independent attestations — roadmap (not yet achieved)

  • SOC 2. A SOC 2 examination is on our roadmap and is in progress / planned. ComplyWise does not currently hold a SOC 2 report, and no statement in this document should be read as a claim that one exists. We will make a report available under NDA once the examination is complete. [Confirm target type — Type I / Type II — and timeline.]
  • Independent penetration testing. Third-party penetration testing is planned as part of our ongoing security program. Where a completed test exists, a summary or letter of attestation can be shared under NDA; until then, we do not represent that an independent penetration test has been performed. [Confirm cadence and scope once engaged.]

We will update this section as attestations are completed. We do not claim certifications, audits, or test results we do not hold.

Subprocessors

ComplyWise uses a small set of subprocessors to deliver the service. An up-to-date list is maintained for customers, and material changes are communicated per the Data Processing Agreement.

  • Vercel Inc. — application hosting and delivery; US and Vercel’s global edge locations.
  • Supabase, Inc. — managed PostgreSQL database and object storage. Supabase itself runs on Amazon Web Services infrastructure, so AWS is engaged as a sub-processor by Supabase rather than directly by ComplyWise. The Supabase project — database and object storage — is in us-east-1 (N. Virginia, USA).
  • Stripe, Inc. — payment processing and subscription billing; US.
  • Resend — transactional email (optional; used only if enabled by the operator).
  • Sentry — application error monitoring (optional; used only if enabled by the operator).

[Confirm the definitive subprocessor list, data categories processed by each, and transfer mechanisms before publication.]

Shared-responsibility summary

Security is a partnership. ComplyWise is responsible for the security of the platform — infrastructure, tenant isolation, encryption, application security, and audit integrity as described above. Customers are responsible for security in the platform: managing their users and roles, enforcing MFA and SSO policies, safeguarding administrator credentials and API tokens, defining retention and access-review practices, and validating the system for their specific regulated use.

Contact

  • Security & vulnerability reports: [security@complywise.com — placeholder]
  • Privacy / data-subject requests: [DPO / privacy contact email]
  • General / sales / trust inquiries: [contact email]

ComplyWise, Inc., [registered address]. Governing law: [Governing law: e.g., State of Delaware, USA]. This whitepaper is provided for informational purposes, is subject to change, and does not create contractual obligations except as expressly stated in a signed agreement between ComplyWise, Inc. and the customer.