Security at Cascade

Cascade runs on Vercel (application hosting) and Supabase (database, sign-in and file storage, on Amazon Web Services in the United States). Both hold independent SOC 2 Type 2 reports. Infrastructure is defined in code and every change is reviewed and tested before release. Production is kept apart from development and testing, which use separate databases.

• Customer data is encrypted at rest with AES-256, including the database, backups and stored files.
• Data in transit is encrypted with TLS 1.2 or higher. Older protocols are refused, every web address redirects to HTTPS, and browsers are told to use HTTPS only (HSTS). Database connections require TLS.
• Files are kept in private storage and opened only through short-lived signed links.
• Connection tokens for integrations are encrypted again inside the application with AES-256-GCM.
• Each closed-out daily report PDF is sealed so any later change to it can be detected.

Every record belongs to one customer company. The database enforces row-level security on every table, and the application checks a person’s company and role on every request. Automated tests that try to reach another company’s data run on every change.

• Access is by role (admin, manager, superintendent, staff, safety manager). Subcontractors see only their own company’s work.
• Sign-in uses one-time codes sent to a verified email or phone, or Google sign-in.
• Administrative access to infrastructure requires multi-factor authentication and is limited to the people who need it. Access is reviewed quarterly and removed when it is no longer needed.
• Administrative actions, including viewing a customer account for support, are recorded.

Every change goes through a pull request and required automated checks: linting, type checks and tens of thousands of automated tests, including access-control tests. Releases are deployed, checked against the live system, and only then promoted. Dependencies are pinned, new package versions wait seven days before use, and third-party build actions are pinned to exact versions.

Dependencies are scanned continuously for known vulnerabilities. Findings are rated by severity and fixed within set timeframes: critical within 7 days, high within 30 days, medium within 90 days. Software that is no longer supported is not used in production. Cascade runs regular internal security assessments of the application.

Application logs and errors are collected centrally, with personal data removed, and reviewed daily. Problems raise alerts to the team. Logs are stored in systems that customers and application users cannot reach or change.

The database is backed up daily. Backups are encrypted, stored separately from the live database, kept for seven days, and cannot be changed or deleted with the application’s credentials. Restores are tested regularly.

Cascade keeps a written incident response plan. If an incident affects a customer’s data, we notify that customer without undue delay and within 72 hours of confirming it, with what happened, what data was involved and what we are doing about it. Every incident is reviewed afterwards and its cause fixed.

Customer data is kept while the subscription is active. When a contract ends, Cascade returns the customer’s reports and files on request and deletes their data within 30 days. Backups containing it expire within seven days after that.

Each provider is reviewed before use and every year after. Job site locations are also sent to public weather and mapping services to show conditions and directions.

Email info@cascadetechnology.ai with “Security” in the subject. We respond within one business day. Our security contact is also published at /.well-known/security.txt.