Security Architecture Overview
A comprehensive overview of the security architecture, controls, and practices built into Call Coach IQ — covering 15 domains from infrastructure and authentication to supply chain integrity and active security testing.
What this document covers
15 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 via Firebase Identity Platform
- 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
- userCompanyMap writable only by backend — never by 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
- Four-tier hierarchy: Agent → Manager → Admin → Super-Admin
- 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 before app logic: global 1,000 req/min; demo analysis 10/5 min
- 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)
- 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: if Firestore is unavailable, public endpoints deny the request
- SHA-256 hashed counter keys — no PII stored in rate limit collection
- Super-admin live override — limit changes take effect within 60 seconds
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)
- 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
- 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 backup daily at 03:00 UTC — 7-day retention — RPO: 24 hrs, RTO: 1 hr
- Cloud Storage object versioning: 30-day non-current retention — RPO: ~zero
- Daily backup verification function at 09:00 UTC; alerts Sentry + email on failure
- Pub/Sub Dead Letter Queue for call processing — no message silently dropped; quarterly DR drills
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 keys; WIF provider scoped to a single workflow file and branch
- Three-layer supply chain: frozen-lockfile (structure) + Sigstore attestation (content) + Socket.dev behavioral scan
- Cross-layer authorization parity matrix on every PR across 5 enforcement layers
- 14 pre-commit hooks and 26 CI workflows including CodeQL static analysis and daily callable IAM audit
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
- 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, and regulatory non-compliance.
Key controls
- Data Processing Agreement (DPA) available for enterprise customers
- IP addresses hashed (SHA-256) before storage; auth tokens excluded from all logs
- Outbound email via Resend with SPF + DKIM domain authentication
- 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: identical allow/deny decision verified across all 5 enforcement layers per 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
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 penetration test reports, DPA requests, or detailed security questionnaire support, contact our sales team.
Common Questions
How is call recording data encrypted and stored in Call Coach IQ?
Call recordings and transcripts are encrypted at rest using AES-256 and in transit using TLS 1.2+. Data is stored in Google Cloud Storage within a dedicated tenant namespace — no cross-tenant access is possible at the storage layer. Per-company encryption keys are derived using HKDF so that a compromise of one key does not affect other tenants.
Does Call Coach IQ support SSO and SAML for enterprise authentication?
Yes. Call Coach IQ supports SAML 2.0-based SSO through Firebase Identity Platform, which integrates with standard enterprise identity providers including Okta, Azure AD, and Google Workspace. TOTP-based multi-factor authentication is also available for all user accounts and can be enforced at the company level by administrators.
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). Bypassing any single layer does not grant cross-tenant access because the other layers enforce the same boundary independently.
What is Call Coach IQ's approach to handling security incidents?
Call Coach IQ maintains documented incident response runbooks covering credential compromise, data exposure, and infrastructure failures. Severity levels map to defined response SLAs: critical incidents receive immediate on-call response; high-severity incidents within four hours. Post-incident reviews are conducted within five business days and findings are incorporated into the security controls reviewed in this document.