Security Architecture Overview
A comprehensive overview of the security architecture, controls, and practices built into Call Coach IQ — covering 16 domains from infrastructure and authentication to supply chain integrity and active security testing.
Inherited from Google Cloud — infrastructure certifications held by Google, not by Call Coach IQ
What this document covers
16 security domains, plain-language and technical
Each section includes a plain-language explanation for general readers, a technical specification for security and engineering teams, and a summary of what each control protects against. The PDF version is suitable for vendor security questionnaires and enterprise procurement reviews.
This document is intended for IT security teams, compliance officers, and enterprise buyers evaluating Call Coach IQ.
Section 01
Platform & Infrastructure
Protects against
Infrastructure breaches, physical media theft, hardware failures, and data in transit interception.
Key controls
- Google Cloud Platform — ISO 27001, SOC 2 Type II, SOC 3, PCI DSS, FedRAMP certified
- Firebase Cloud Functions Gen 2 / Cloud Run backend
- TLS 1.2+ enforced at platform ingress — plain HTTP rejected
- HSTS: max-age=63072000; includeSubDomains; preload
Section 02
Authentication & Identity
Protects against
Brute-force attacks, session hijacking, stolen tokens, and deferred access after offboarding.
Key controls
- Firebase Authentication — short-lived JWTs with 1-hour expiry
- TOTP multi-factor authentication — admins can require it per user, or platform-wide
- SAML 2.0 / OIDC single sign-on on the Enterprise plan, one Identity Platform tenant per company
- checkRevoked: true on every server-side token verification call
- Progressive login lockout tracked in Firestore (not browser-local)
Section 03
Multi-Tenancy & Data Isolation
Protects against
Cross-tenant data access, IDOR attacks, and client-side subscription manipulation.
Key controls
- All company data scoped to companies/{companyId}/... in Firestore
- Company membership records writable only by the backend — never by the client SDK
- Company membership validated server-side on every Cloud Function call
- Billing fields (plan, stripeCustomerId) blocked from all client writes
Section 04
Role-Based Access Control
Protects against
Privilege escalation, cross-team data access, and AI-score tampering.
Key controls
- Role hierarchy: Agent → Manager → Admin → Super-Admin, plus two read-only roles (External User, Insights Viewer)
- Granular capability flags checked at every API and Firestore rule boundary
- Fail-closed defaults: missing config → least-privileged outcome
- Field-level write restrictions on role, score, embedding, and billing fields
Section 05
Network & Transport Security
Protects against
Clickjacking, XSS injection, MIME sniffing, referrer leakage, and IP forgery in rate limit contexts.
Key controls
- Full HTTP security header set (HSTS, X-Frame-Options DENY, X-Content-Type-Options, Referrer-Policy)
- Dual-layer CSP: per-request nonce + SHA-256 hash allowlisting — no unsafe-inline in production
- Edge rate limits applied before application logic, with separate budgets for anonymous and authenticated traffic
- CDN cache default: no-store for all routes; public caching requires explicit allowlist entry
Section 06
Application Security
Protects against
Bot abuse, replay attacks, cross-site request forgery, SSRF, and anonymous write injection.
Key controls
- Firebase App Check enforced globally — reCAPTCHA Enterprise (web), Play Integrity / DeviceCheck (mobile)
- Single-use (replay-proof) App Check tokens on highest-risk public callables
- Cloudflare Turnstile + reCAPTCHA Enterprise + Firestore-backed rate limits on public forms
- All Firestore public-write collections protected by hasOnly() + hasAll() field allowlists
Section 07
API & Webhook Security
Protects against
Webhook replay attacks, payload tampering, and secret leakage in source code.
Key controls
- Stripe webhook: HMAC-SHA256 via stripe.webhooks.constructEvent() before any payload read
- Resend webhook: Svix three-header signature verification (svix-id, svix-timestamp, svix-signature)
- Outbound webhooks: signed deliveries, SSRF-guarded destinations re-checked before each send
- Customer identity withheld from outbound payloads unless a super-admin enables it per endpoint
- All secrets in Google Secret Manager — never in source, config files, or committed env vars
- Automated lint check blocks any raw process.env read outside sanctioned loader files
Section 08
Rate Limiting & Abuse Prevention
Protects against
Cost amplification attacks, credential stuffing, API flooding, and quota exhaustion.
Key controls
- Firestore-backed fixed-window rate limiter — atomic, persistent across cold starts
- Fail-closed policy: a public request that cannot be checked against its limit is denied, not allowed through
- SHA-256 hashed counter keys — no PII stored in rate limit collection
- Platform operators can tighten limits live, without a redeploy
Section 09
Data Protection & Encryption
Protects against
Data at rest exposure, man-in-the-middle attacks, and transcript/recording leakage.
Key controls
- AES-256 encryption at rest on all Firestore, Cloud Storage, and Functions data (GCP-managed)
- Application-layer AES-256-GCM with per-company keys for integration credentials and webhook secrets
- TLS 1.2+ in transit for all browser, Firebase, and Cloud Function communication
- AI embedding vectors (used for semantic search) — server-write-only, no client SDK access
- IP addresses SHA-256 hashed before storage; PII excluded from all server logs
Section 10
Audit Logging
Protects against
Undetected privilege abuse, unauthorized configuration changes, and post-incident blind spots.
Key controls
- Per-company audit log at companies/{companyId}/auditLog capturing actorUid, actorEmail, action, details, timestamp
- Audit entries are append-only and carry a server-assigned timestamp; security rules reject client-supplied times, so entries cannot be backdated
- Audited events: user invitations, role changes, team management, AI config, rubric edits, notification policy
- Structured JSON logs in Cloud Functions for all security-relevant events
Section 11
Disaster Recovery & Business Continuity
Protects against
Data loss from infrastructure failures, accidental deletion, and silent processing failures.
Key controls
- Firestore automated daily backups — 7-day retention — RPO 24 hrs / RTO 1 hr (design targets)
- Cloud Storage object versioning: 30-day non-current retention — RPO: ~zero
- Automated daily backup verification, alerting on any failure
- Pub/Sub Dead Letter Queue for call processing — no message silently dropped; documented restore runbooks
Section 12
CI/CD & Supply Chain Security
Protects against
Compromised deploy credentials, poisoned dependencies, and authorization regressions.
Key controls
- Workload Identity Federation — no long-lived deploy keys; provider trust scoped to this repository and to the refs permitted to deploy
- Three-layer supply chain: frozen-lockfile (structure) + Sigstore attestation (content) + Socket.dev behavioral scan
- Authorization parity matrix on every PR — 107 decision rows across 9 actor profiles, spanning 5 enforcement layers
- 47 CI workflows including CodeQL static analysis and a daily callable IAM audit, plus pre-commit hooks on every commit
Section 13
Monitoring & Incident Response
Protects against
Undetected production errors, silent security regressions, and IAM drift.
Key controls
- Sentry integrated across browser, server, and edge — new-issue and error-rate-spike alert rules
- Deployed dependency verification: every release probes its AI, reCAPTCHA, database and monitoring credentials and rolls back automatically if one is misconfigured; re-checked hourly between releases
- Structured logging for auth failures, rate limit violations, App Check rejections, webhook failures
- Daily callable IAM audit — opens a GitHub issue tagged security/iam-drift on any deviation
- Firestore and Storage rules drift detection: live-deployed rules compared byte-for-byte against source on schedule
Section 14
Privacy & Compliance Controls
Protects against
PII leakage through logs, email data disclosure, indefinite data retention, and regulatory non-compliance.
Key controls
- Data Processing Agreement (DPA) available for enterprise customers
- Data stored in Google Cloud us-central1; region is a per-deployment configuration
- Tenant deletion is a two-party workflow — a company admin requests, a platform super-admin must approve
- 14-day cancellable grace period after approval, then an automated sweep purges the company permanently
- Legal hold blocks approval outright and is re-checked immediately before the purge, so a hold arriving mid-grace still stops it
- Deletion requests actioned within 30 days; data removed within 90 days of cancellation
- After a purge, data persists only in disaster-recovery copies — up to 7 days in database backups, 30 days in file versions — then expires automatically
- Breach notification within 72 hours, committed in the Data Processing Agreement, which also lists sub-processors
- Call recordings: 30-day non-current version retention, then removal; purged with the tenant on deletion
- Gemini used as a paid service — customer prompts and responses are not used to train or improve Google models
- IP addresses hashed (SHA-256) before storage; auth tokens excluded from all logs
- Outbound email via Resend with SPF + DKIM domain authentication
- AI voice agent escalation alerts go only to a tenant-nominated address — the agent cannot send email, and recordings and transcripts are never attached
- Demo reports keyed by unguessable tokens — scoped to the specific demo session
Section 15
Security Testing
Protects against
Authorization regressions, App Check bypass, fail-open lockout bugs, and rule drift.
Key controls
- Authorization parity matrix: the same allow/deny decision pinned across every enforcement layer a given gate implements, on every PR
- App Check source guards + live HTTP enforcement tests (Group A + B) on every CI build
- Admin SDK fail-closed hardening tests — lockout never fails open under any Firebase SDK error
- Firestore and Storage rules unit tests under live emulator; CodeQL semantic analysis on every PR
Section 16
AI Voice Agent
Protects against
Disclosure of protected account data to callers, abuse of service-to-service endpoints, runaway call costs, and undisclosed AI calls.
Key controls
- Optional Enterprise capability, off unless a tenant is explicitly entitled and configured
- Protected account fields are removed from the model’s context before the call, not withheld by instruction
- No agent tool accepts a customer identifier — the customer is fixed by the call itself
- Internal endpoints reachable only by the voice service’s own identity; carrier endpoints verify every request signature
- AI disclosure recorded on every call, with an alert on any call answered without one
Download the full PDF
The complete Security Architecture Overview is available as a formatted PDF — suitable for sharing with your security team, compliance reviewers, or vendor questionnaire process. No form, no email required.
Download PDF — Call Coach IQ Security OverviewFor security questionnaire support or our Data Processing Agreement, contact our sales team.
Reporting a vulnerability
If you believe you have found a security vulnerability in Call Coach IQ, email support@callcoachiq.com with the steps to reproduce it. Please do not access, modify or retain data belonging to other customers while investigating. The same contact is published in our security.txt.
Common Questions
How is call recording data encrypted and stored in Call Coach IQ?
Call recordings and transcripts are encrypted at rest with AES-256 by Google Cloud and in transit with TLS 1.2+. Recordings are stored in Google Cloud Storage under a company-scoped path, and access is checked against the requesting user's company and role on every read. The most sensitive credentials — integration access tokens and webhook signing secrets — are additionally encrypted at the application layer with AES-256-GCM, using a separate key derived for each company, so they are unreadable to anyone holding database access alone. Recordings and transcripts are not in that application-layer set; they rely on Google's encryption at rest plus the tenant-scoped access controls.
Does Call Coach IQ support SSO and SAML for enterprise authentication?
Yes, on the Enterprise plan. Each company gets its own Google Cloud Identity Platform tenant and can connect a SAML 2.0 or OpenID Connect identity provider. Sign-in is service-provider-initiated, with one identity provider per company; SCIM provisioning is not currently supported. Separately, TOTP multi-factor authentication is available on every plan: a company administrator can require it for individual users, and it can also be enforced platform-wide.
How does Call Coach IQ enforce tenant isolation — can one company's data be accessed by another?
Tenant isolation is enforced at three independent layers: Firestore security rules (which scope every query to the authenticated user's company), Cloud Functions middleware (which re-validates company membership and role on every callable invocation), and storage access controls (which namespace all files by company ID). Each layer enforces the same boundary on its own, so a defect in one is not by itself enough to expose another company's data, and an automated test matrix checks on every change that the layers reach the same decision.
What is Call Coach IQ's approach to handling security incidents?
Production errors and security-relevant events — authentication failures, rate-limit violations, attestation rejections, webhook failures, IAM drift — are monitored and alerted on automatically, and documented runbooks cover credential compromise and data recovery. If an incident involves customer data, the affected customer is notified without undue delay and in any event within 72 hours, as committed in our Data Processing Agreement. Researchers can report suspected vulnerabilities to the contact published in our security.txt file.
Does Call Coach IQ have its own SOC 2 report or a penetration test?
Not yet. The ISO 27001, SOC 2 Type II, SOC 3, PCI DSS and FedRAMP certifications shown on this page belong to Google Cloud and cover the infrastructure Call Coach IQ runs on; Call Coach IQ does not hold them in its own name, and has not commissioned a third-party penetration test. The controls described here are verified by automated security testing on every change. For a procurement review we can complete your security questionnaire and provide our Data Processing Agreement.
How long does Call Coach IQ retain customer data, and how is deletion handled?
Data is retained while the account is active. After cancellation it is deleted within 90 days, and deletion requests raised separately are actioned within 30 days. A company administrator can request deletion of their own company's data from within the application, but that request does not execute on its own: a platform super-administrator must approve it, which starts a 14-day grace period the company administrator can cancel. Only then does an automated sweep permanently purge the company. A legal hold blocks approval outright and is re-checked immediately before the purge, so a hold arriving during the grace period still stops it. After the purge, copies remain only in disaster-recovery storage — up to 7 days in database backups and up to 30 days as retained versions of recordings and files — and then expire automatically.