Security Policy

Overview

Close-Rate handles sales call recordings, transcripts and coaching reports for its customers. These are the security controls that protect that data and the platform.

Encryption

In Transit

• Traffic between your browser and Close-Rate, and between Close-Rate and its providers, uses TLS 1.2 or higher

• Our API is served over HTTPS behind an AWS Application Load Balancer, and the website over HTTPS through AWS Amplify and CloudFront

• HTTP requests to the API are 301-redirected to HTTPS, and API responses carry an HSTS (Strict-Transport-Security) header

• Traffic from our load balancer to the application stays inside our private AWS network and is not separately encrypted. Database connections use TLS

• Calls to our providers (Anthropic, OpenAI, AssemblyAI, TypeSafe, Zoom, RingCentral, Clerk) use HTTPS

At Rest

• Database: Amazon RDS PostgreSQL with AES-256 encryption enabled

• File Storage: Amazon S3 with server-side encryption (SSE-S3)

• Search Index: transcript search indexes (text chunks and embeddings) are stored in the same encrypted Amazon Aurora PostgreSQL database (pgvector), not in a separate search service

• OAuth Tokens: Encrypted using Fernet symmetric encryption before database storage, with a dedicated encryption key

Authentication & Authorization

• Sign-in and user accounts are handled by Clerk

• Requests to our API for a workspace's data must carry a valid JWT signed with RS256 (asymmetric keys); a running Zoom import's progress can also be read with a token issued for that import. Webhooks from Stripe, Clerk and Zoom are checked against the sender's signature instead; a Zoom uninstall notice without a valid signature is confirmed with Zoom before anything is deleted. Health checks, the Zoom and RingCentral OAuth callbacks and a few public endpoints, such as the sample-report request form, need no sign-in

• JWTs are validated on every signed-in request using Clerk's JWKS endpoint — signature, expiration (exp), issued-at (iat) and issuer (iss) are all verified, with a 30-second allowance for clock differences

• Role-based access control (RBAC): coach, sales, and admin roles — coach and admin have full organization access. A sales rep's own lists and reports show only that rep's calls; a rep can also open any call in their workspace when they have its link

• Customer requests are checked against the workspace of the person making them, in our application code. Close-Rate staff can open a customer's workspace to support that customer, and our internal admin tools and background jobs can read across workspaces

• Zoom and RingCentral connect through OAuth 2.0 and ask only for read access. Zoom's permissions cover every user on the connected Zoom account, so a coach can import the team's recordings

Network Security

• Backend hosted on AWS ECS (Fargate) with managed networking and automatic scaling

• Database accessible only within the VPC — not exposed to the public internet

• Transcript search indexes live in that same database, inside the same private AWS network; there is no separate search endpoint

• Browsers can call our API only from an explicit list of Close-Rate's own web addresses (CORS); a wildcard origin is refused in production

• There is no SSH access to the servers that run the backend. Our engineers can run one-off tasks inside our private AWS network to diagnose problems

Credentials and Secrets

• The application's own credentials (the database password, API keys and the token encryption key) are kept in AWS Secrets Manager and given to the application when it starts. They are not stored in our source code

• Sign-in tokens, OAuth codes and signed download links are replaced with REDACTED in the web addresses our logs record

• Integration tokens are stored encrypted and scoped to individual organizations

Application Security

• Database queries pass the values they are given as bound parameters. Most queries use the SQLAlchemy ORM; hand-written SQL statements, such as those for transcript search, bind their values the same way

• Most API routes validate their input against a typed schema (Pydantic models). The others check their fields in code

• Production writes application logs at INFO level and above. An automated test reads every logging statement at those levels in our application code and fails if one writes a value that our code names as a person's name or email address, a customer, company or workspace name, a meeting topic, a file name, a title, a question someone asked or the AI's own reasoning, or if one writes a storage path without first removing the file's name from it. The test allows two kinds of line: the line for a failed upload names the file, and billing changes made by Close-Rate staff name the staff member. Because the test goes by those names, other values can still reach the logs: errors are logged with their text

• Stack traces stay in our server logs and are not sent to the browser. A request that fails on our side gets a generic message, or a fixed sentence saying what could not be done, instead of the text of the error that caused it; an automated test fails if a route builds such a response from the error it caught. A result that lists a problem with one item, such as one file in a batch upload, can still include that error's text. Work that continues in the background, such as uploading or importing a recording, analyzing a call or writing a script, can still show the text of the error that stopped it

• File uploads are limited to supported audio, video and document formats, with size limits

Vendor Security

Vendors that hold or process customer data include:

• Amazon Web Services: SOC 1/2/3, ISO 27001, PCI DSS Level 1, HIPAA eligible

• Clerk: Sign-in and user accounts. Has a SOC 2 Type II report; GDPR compliant

• Anthropic (Claude): Has a SOC 2 Type II report. Our primary analysis and reasoning model. It powers coaching-report generation and AI Insights chat over conversation transcript text. Anthropic's commercial terms say it may not train models on customer content sent through its services

• OpenAI: Has a SOC 2 Type II report. Used for text embeddings, participant extraction and other short text tasks, profile narrative updates, and as a fallback for ranking evidence. It is also the backup model, used when the primary model fails, for AI Insights answers, sales scripts, objection cheat sheets and the practice buyer library. It receives transcript text. OpenAI says data sent to its API is not used to train its models unless the customer opts in to share it

• TypeSafe: Chooses the kind of answer a coaching question needs, and ranks transcript excerpts the person asking is already allowed to see against that question; it receives the question and short excerpts

• AssemblyAI: SOC 2 Type 2 report, audited annually by an independent firm. Used only to transcribe call audio. Since October 15, 2026, our account has been opted out of AssemblyAI's model improvement program, which AssemblyAI says means it does not use the call audio we send it to train its models or for benchmarking. The account is set so that AssemblyAI begins deleting each call's audio and transcript one day after the request; it keeps certain metadata for logging and billing, and its terms let it keep de-identified data made from the audio for purposes other than training its models

• Zoom: Has a SOC 2 Type II report and ISO 27001 certification

Security Incident Reporting

If you discover a security vulnerability, please report it responsibly to client-services@close-rate.com. We reply to confirm we received the report, and again with our assessment. See our Incident Response Policy for full details.