Security

Last updated: April 20, 2026

Our Approach

Security is continuous work, not a certification on a wall. This page describes the practices we have in place today. We update it as our posture changes.

1. Encryption

  • In transit: All connections between your browser or device and CleanRev use TLS 1.3 with strong cipher suites. HTTP requests are redirected to HTTPS. HSTS is enforced.
  • At rest: Customer data in our primary database is encrypted at rest using AES-256. Backups are encrypted with independent keys.
  • Passwords: User passwords are hashed using bcrypt with a per-user salt. We never store or log plaintext passwords.
  • Secrets: Internal API keys and credentials are stored in encrypted secret stores and rotated regularly. They are never committed to source control.

2. Authentication and Access Control

  • Multi-factor authentication (MFA): Available for all user accounts and required for administrative access.
  • Role-based access control (RBAC): Permissions are scoped to Owner, Admin, Manager, and Employee roles. Users only see the data they need.
  • Tenant isolation: We use row-level security in our database so that one customer cannot access another customer's data, even if an application bug bypasses authorization checks.
  • Session management: JWT-based sessions with short-lived access tokens and rotating refresh tokens. Sessions can be revoked by the Account Owner.
  • Least-privilege access: Employee access to production systems is granted only to roles that need it, logged, and reviewed periodically.

3. Infrastructure

  • Edge and hosting: Cloudflare Workers and Pages for our web and API tier. Neon for our PostgreSQL database. Both providers hold SOC 2 Type II attestations.
  • DDoS protection and WAF: Cloudflare's global network provides volumetric DDoS mitigation and a Web Application Firewall with managed rulesets.
  • Rate limiting: API endpoints are rate-limited by IP, user, and tenant to resist abuse.
  • Hosting region: Primary data processing is in the United States. Edge caching uses Cloudflare's global network.

4. Application Security

  • Input validation: We use end-to-end schema validation (Zod) for every API input and output. Untrusted data never reaches the database raw.
  • SQL injection protection: All database access uses parameterized queries via Drizzle ORM.
  • XSS protection: Content is sanitized before rendering; Content Security Policy (CSP) headers reduce exploit surface.
  • CSRF protection: State-changing requests require either a bearer token or double-submit cookie.
  • Dependency scanning: Automated dependency updates via Dependabot. Critical vulnerabilities trigger expedited review and patch.
  • Static analysis and linting: Enforced in CI; builds fail on security lints.
  • Pre-commit hooks: Block commits containing secrets or credentials.

5. Monitoring and Response

  • Observability: Application logs, error reporting, and uptime monitoring cover our production environment 24/7.
  • Anomaly detection: Failed-login patterns, rate-limit trips, and unusual query volumes trigger alerts.
  • Incident response: We maintain a documented incident response process with defined severity tiers, on-call rotation, and post-incident review.
  • Breach notification: In the event of a confirmed breach affecting personal information, we notify affected users and supervisory authorities on the timelines required by applicable law — within 72 hours under GDPR, and without unreasonable delay under US state laws.

6. Backups and Disaster Recovery

  • Backups: Automated daily backups with point-in-time recovery for our primary database, retained for 30 days.
  • Encryption: Backups are encrypted at rest with keys separate from the production database.
  • Geographic redundancy: Backup storage is replicated across multiple regions.
  • Recovery testing: We periodically test restore procedures.

7. Development Practices

  • Code review required on all changes before merge to production branches
  • Automated test suite (unit, integration, end-to-end) runs on every change
  • Separate staging and production environments with non-prod data
  • Production deployments through continuous delivery with rollback capability
  • Employee workstations have full-disk encryption and screen-lock timeouts

8. Data Handling

  • Data minimization: We collect only what is necessary to provide the Services. See our Privacy Policy for specifics.
  • Retention: Data is retained only as long as necessary for the purposes disclosed in the Privacy Policy, or as required by law.
  • Deletion: Users may export and delete their data. Deletion is propagated to backups within the backup retention cycle.
  • Payment data: We do not store credit card numbers. All payment data is handled by Stripe, a PCI-DSS Level 1 service provider.

9. Sub-Processors

Our sub-processors are disclosed in the Privacy Policy. Each is bound by a written data processing agreement and security terms consistent with our commitments to you.

10. Compliance Posture

  • GDPR: We support data subject rights under Articles 15–22 and comply with Article 33 breach notification timelines.
  • CCPA / CPRA and other US state privacy laws: We support consumer rights for access, correction, and deletion and honor opt-out requests.
  • SOC 2: We have not completed a SOC 2 audit. We plan to pursue a SOC 2 Type II attestation as we scale. We will update this page when the audit is in progress.
  • ISO 27001: Not currently certified.
  • HIPAA: CleanRev is not a HIPAA-compliant platform and is not intended for protected health information. Do not store PHI in CleanRev.

We publish this honestly. Saying we hold a certification we don't hold is worse than naming the gap.

11. Reporting a Vulnerability

We welcome responsible disclosure from security researchers. If you believe you have found a vulnerability, please email security@cleanrev.io with:

  • A description of the vulnerability
  • Steps to reproduce
  • The potential impact
  • Any proof-of-concept or supporting material

We commit to:

  • Acknowledging your report within 3 business days
  • Investigating in good faith
  • Keeping you informed of remediation progress
  • Not pursuing legal action against researchers acting in good faith under this policy, within the bounds of applicable computer-misuse laws

We do not currently operate a paid bug-bounty program. If we introduce one, we will publish terms here.

Out of Scope

  • Denial-of-service, volumetric, or brute-force attacks
  • Social engineering of CleanRev employees or contractors
  • Physical attacks on our offices or hardware
  • Issues affecting only old or unpatched browsers
  • Reports generated solely by automated scanners without demonstrated impact

12. Contact

CleanRev, Inc.
Attn: Legal
601 16th Street, C448
Golden, CO 80401
United States