CoreClips AI, operated by Critso
Last updated: July 17, 2026 (draft)
Security is foundational to how we built CoreClips AI, particularly given the sensitive nature of the video content our customers — including legal, healthcare, and education teams — process through the platform. This page describes the technical and organizational measures in place. For our data-handling practices generally, see our Privacy Policy; for our data-processing commitments to enterprise customers, see our Data Processing Agreement.
In transit. All data transmitted between your browser or API client and CoreClips AI is encrypted using TLS/HTTPS. [VERIFY: confirm current minimum TLS version enforced at the edge/load balancer — not something the application codebase itself controls.]
At rest. Uploaded video files and generated outputs are stored in Cloudflare R2, encrypted at rest. Passwords are never stored in plain text — we use bcrypt password hashing with a high work factor before storing any credential.
Two-factor authentication. Login requires a two-step process: password verification followed by a one-time verification code sent to your registered email address, for all standard web logins.
Session tokens. Authenticated sessions use signed JSON Web Tokens (JWTs), verified using asymmetric (RS256) signing keys.
Role-based permissions. Organization (enterprise/team) accounts support role-based access control: administrators can assign roles to members that govern what each person can view, edit, or manage within the organization's workspace, including branding assets, billing, and video content.
Database-level tenant isolation. Our database enforces row-level security so that queries are scoped to the authenticated user's own data and organization, as an additional layer beyond application-level authorization checks. [VERIFY: this describes the architectural intent (Postgres RLS session variables set per request) — before publishing, confirm with engineering that RLS policies are consistently applied across all tenant-scoped tables, not just the subset in place at time of this draft.]
Account lockout. Repeated failed login attempts temporarily lock an account to reduce the risk of automated password-guessing attacks. [VERIFY: confirm with engineering whether this protection has been hardened to work consistently across all backend instances before making this claim in a customer-facing context — a prior internal review found the lockout counter was tracked per-process rather than centrally, which weakens this protection under horizontal scaling. This should be fixed, or the claim scoped accordingly, before publication.]
Automatic video deletion. Uploaded video files are automatically and permanently deleted from storage 7 days after upload, as a default privacy-by-design measure — we don't retain your raw video content indefinitely by default. A warning notification is sent approximately 2 days before scheduled deletion.
Account deletion. When you delete your account, your content and personal data are processed for deletion as described in our Privacy Policy.
Backups. We maintain [PLACEHOLDER: describe actual backup cadence and retention — e.g. "automated daily backups retained for N days" — confirm the real figures with infrastructure/engineering rather than asserting a number here] to support recovery from data loss events, stored with the same encryption standards as production data.
[PLACEHOLDER: this section requires real input from engineering/infrastructure — a public trust page claiming disaster-recovery capabilities (RTO/RPO targets, multi-region failover, etc.) must reflect what's actually tested and in place, not aspirational architecture. As of this draft, the codebase shows a single self-managed deployment target rather than confirmed multi-region redundancy; do not publish specific continuity claims until this is confirmed with the infrastructure team.]
Least-privilege processing. Video processing, transcription, and AI summarization run as isolated background jobs, separated from the customer-facing web application.
Vulnerability management. [PLACEHOLDER: describe your actual practice — e.g. dependency scanning cadence, penetration testing schedule, responsible disclosure program. Not confirmed in this draft; do not claim a specific practice (such as "regular penetration testing") unless it is actually and currently true.]
Responsible disclosure. If you are a security researcher and believe you've found a vulnerability in CoreClips AI, please report it to [PLACEHOLDER: security@critso.com]. [PLACEHOLDER: confirm whether Critso wants to publish a formal responsible-disclosure/bug-bounty policy with scope and safe-harbor commitments — recommended before inviting external researchers to test the live system.]
Critso does not currently hold [PLACEHOLDER: confirm — as of this draft, no evidence of SOC 2, ISO 27001, HIPAA, or similar third-party certification was found] formal third-party security certifications. We are happy to complete customer security questionnaires and discuss specific enterprise security requirements — contact [PLACEHOLDER: security@critso.com]. [PLACEHOLDER: if pursuing SOC 2 or ISO 27001 is on the roadmap, note the target timeline here once confirmed — enterprise prospects often ask directly.]
For security questions, questionnaires, or to report a vulnerability, contact [PLACEHOLDER: security@critso.com].