Security & Governance

Our SSDLC is intentionally lightweight but every stage has at least one enforced control. The phases below describe what is required for any change to reach production.

Design and threat modelling

• Changes that touch authentication, authorization, encryption, third-party integrations, or data retention require a written design note in the pull request describing the data flows and the trust boundaries crossed.
• For new integrations, we identify the OAuth scopes requested, the data fields read or written, and any new sub-processors before implementation begins.

Secure coding

• TypeScript with strict mode; any is avoided.
• All database queries are parameterized through the Neon serverless driver — no string concatenation.
• Webhook endpoints verify HMAC-SHA256 signatures with timing-safe comparison and a timestamp window before any side-effecting work runs.
• OAuth tokens are encrypted with AES-256-GCM before persistence; the key lives only in the application environment, never in source or the database.
• Tenant isolation is enforced by an account_id filter on every customer-data query, surfaced at the type system level.

Code review

• All changes to main go through a pull request with at least one reviewer. Self-merges of security-relevant changes are prohibited.
• Reviewers consult the OWASP Top 10 informally; high-risk paths (auth, crypto, SQL, webhooks) receive extra scrutiny.

Automated checks (CI)

• SAST: GitHub CodeQL runs the security-and-quality query suite on every push, every pull request, and weekly. Findings are tracked in the repository's Security tab.
• Dependency scanning: npm audit runs on every push and daily; GitHub Dependabot raises pull requests for vulnerable dependencies.
• Type checking and linting: tsc --noEmit andnext lint must pass before merge.

Deployment

• Every pull request gets an isolated Vercel preview deployment with its own preview secrets — production secrets are never reachable from previews.
• Promotion to production happens only after the PR is merged to main; builds use the same artefact that was reviewed.
• Database schema changes ship as versioned migrations checked into source control and reviewed alongside the code that uses them.

Periodic dynamic testing (DAST)

• OWASP ZAP baseline scans are run against production before each major release and at minimum quarterly. Reports are retained internally.

Post-deployment monitoring

• Application errors and traffic anomalies are observable through Vercel's built-in telemetry; database health is monitored via Neon.
• Production incidents follow the process in §5 (Incident management).

Qualitative protects customer data through a combination of platform-provided controls, column-level encryption for sensitive fields, and strict tenant isolation enforced both in application code and at the database level.

Transport security

• All traffic between the user's browser and the application is HTTPS only (TLS 1.2+).
• All traffic between the application and our database, OAuth providers, AI provider, and payment processor is encrypted in transit.
• HTTP Strict Transport Security (HSTS) is enabled on the production domain.

Data at rest

• Database storage is encrypted at rest by our database provider (Neon).
• OAuth tokens (Google, Zoom, Microsoft Teams) are additionally encrypted at the column level using AES-256-GCM with a key held only in the application environment, so an attacker with read-only database access cannot retrieve usable tokens.
• The encryption key is held outside the database, rotated only via a versioned migration path (the stored format includes a version prefix so multiple keys can coexist during rotation).

Authentication and access control

• End-user authentication is delegated to Google via OAuth 2.0; we do not store passwords.
• Session management uses signed, encrypted JWTs (NextAuth.js v5).
• Multi-tenant isolation: every database query for customer-owned data carries anaccount_id filter enforced at the type system level; cross-tenant access is structurally prevented at the application layer.
• Administrative access to the platform is restricted to an allow-list of emails (env variable ADMIN_EMAILS) and is gated behind the same Google OAuth flow as normal users, with 2FA recommended at the Google account level.

Webhooks and integrations

• Inbound webhooks (Stripe, Zoom) are verified by HMAC-SHA256 signature against a provider-issued secret, with timing-safe comparison and a 5-minute replay window.
• OAuth state tokens use a single-use, signed cookie set with HttpOnly, Secure, and SameSite=Lax flags.

Identification

• Dependencies are pinned via package-lock.json; npm audit is consulted on every build and during dependency upgrades.
• We subscribe to security advisories for the runtime (Node.js LTS), framework (Next.js), and core libraries we ship.
• Customer or external reports may be sent to security@qualitative.one; we acknowledge receipt within 2 business days.

Triage and remediation SLAs

We classify vulnerabilities by CVSS v3.1 severity and target the following remediation windows from confirmation:

• Critical (9.0–10.0): 7 calendar days.
• High (7.0–8.9): 30 calendar days.
• Medium (4.0–6.9): next monthly maintenance window.
• Low (< 4.0): best-effort, tracked publicly.

Disclosure

Vulnerabilities affecting customer data trigger the Incident Response process (§5). We do not run a bug-bounty program at this time but welcome responsible-disclosure reports and credit reporters in published postmortems with permission.

What we store

• Account data: name, email, profile image, organization domain.
• Meeting data: calendar metadata, transcripts (text), and the URLs to recordings hosted by the source platform (Google Meet, Zoom, etc.). We do not store the recording video files ourselves.
• Derived data: AI-extracted insights, summaries, and draft emails.
• Integration credentials: OAuth access and refresh tokens, encrypted at the column level as described in §1.

Retention

• Customer data is retained for as long as the customer's account is active.
• Individual meetings, extracts, and email drafts can be deleted by the customer at any time from within the product.
• On account deletion (initiated by the customer via privacy@qualitative.one), we permanently delete all customer data within 30 days. Database backups are purged on their normal cycle (managed by Neon, typically 7 days).

Data portability

Customers can request a machine-readable export of their data in JSON format at any time by emailing privacy@qualitative.one. We provide the export within 30 days.

AI processing

Transcript text is sent to Google Gemini for processing under Google's commercial terms, which prohibit using customer content to train AI models. No Zoom identifiers, URLs, or OAuth credentials are sent to the AI provider — only the transcript text.

Detection

• Application errors and platform health are monitored through Vercel Observability.
• Database health is monitored through Neon's built-in metrics.
• Customer-reported issues route to support@qualitative.one; anything tagged as a possible security event is escalated to the on-call engineer.

Severity tiers

• P0 — Critical: unauthorized exposure of customer data, or full Service outage > 60 minutes.
• P1 — High: partial outage or degraded data accuracy affecting all customers.
• P2 — Moderate: feature broken for some customers; workaround available.
• P3 — Low: minor defect with no material impact.

Response

• On-call engineer acknowledges P0/P1 within 1 hour.
• P0 incidents trigger immediate customer notification (within 72 hours for any personal-data breach, per GDPR Art. 33 obligations).
• P1 incidents trigger customer notification within 7 days where the impact warrants it.
• A written postmortem covering timeline, root cause, customer impact, and remediation is published within 14 days of incident resolution for P0/P1 events.

Communication

Affected customers are notified via the email on file. Subscriber-wide announcements use the same channel; we do not maintain a separate status page at this time.

Hosting and sub-processors

Qualitative is hosted on Vercel and uses the following sub-processors. Each is itself attested under one or more industry standards (SOC 2, ISO 27001, PCI DSS as applicable):

Dependency management

• Application runtime is Node.js LTS, currently Node 22.
• All Node.js dependencies are pinned via package-lock.json.
• Dependency vulnerabilities are tracked through GitHub's Dependabot alerts andnpm audit.
• Major version upgrades go through a manual review checklist before merge.

Change management

• Production deploys go through Vercel's preview-then-promote pipeline.
• Database schema changes are versioned migrations stored in source control; all changes are reviewed before merge.
• Secrets are stored in Vercel environment variables, scoped per environment (production, preview, development).

Qualitative does not currently hold its own SOC 2 or ISO 27001 attestation.We are an early-stage product. Achieving these attestations involves expense and process overhead that is not yet justified by our customer base.

We mitigate this by relying exclusively on sub-processors that are attested under SOC 2 and/or ISO 27001 for the components that handle data at scale (hosting, database, AI processing, payments). The application layer we build on top enforces the additional protections described above (tenant isolation, column-level token encryption, signed webhooks).

We will revisit this stance as our customer base grows, and we're happy to discuss specific compliance needs with prospective customers. Email security@qualitative.one.

• Security issues and responsible disclosure: security@qualitative.one
• Privacy and data-subject requests: privacy@qualitative.one
• General support: support@qualitative.one