Data Handling

This document is a working draft and is currently under review. Specific values (regions, retention windows, response targets, RPO/RTO numbers) describe our current operating posture and may change as the product matures. For the binding statement on any specific topic, email hello@nexprove.com. To report a suspected vulnerability, see Vulnerability disclosure on the Support page or email security@nexprove.com.

The AI Recruiter is operated by Nexprove. The table below summarizes every data category we touch, where it lives, and how long we keep it. Detailed retention rules are in Retention; storage regions are in Storage locations.

We use managed cloud infrastructure rather than self-hosted hardware. Persistent customer data lives in the United States by default. Alternative regions are available for enterprise customers on written request.

• Application database — Neon Postgres in AWS us-east-1 (N. Virginia). Neon stores branch data on encrypted S3 with compute nodes running in the same region.
• Web application — Next.js on Vercel. HTTP traffic terminates at Vercel's global edge; rendering and server actions run in Vercel Functions in US regions (iad1 primary).
• Realtime voice media — LiveKit Cloud routes media through the SFU region closest to the participant (typically US East or US West for North American sessions) to minimize latency. Audio is not written to durable storage in this path.
• Agent workers — Python interview agents run on LiveKit Cloud Agents in the same SFU region as the session. Workers are stateless and do not retain transcripts after a session ends.
• Inference providers — STT, LLM, and TTS calls are brokered through LiveKit Inference to Deepgram, Google Gemini, and Cartesia in US regions. Provider retention is covered in Subprocessors.

Encryption is applied at every layer where data moves or rests. We rely on cloud-provider managed keys today and have not yet introduced customer-managed keys (CMK / BYOK); this is on the roadmap for enterprise customers.

• In transit (public) — all browser and API traffic is served over TLS 1.3 (TLS 1.2 negotiated for legacy clients), with HSTS enabled and HTTP/2 or HTTP/3 on Vercel's edge.
• In transit (realtime) — voice is delivered over WebRTC with DTLS-SRTP (AES-128-GCM SRTP); the signaling channel uses WSS over TLS 1.3.
• In transit (internal) — service-to-service calls (Vercel Functions to Neon, agent worker to LiveKit Inference) use TLS 1.2 or higher with certificate validation pinned to provider CAs.
• At rest (database) — Postgres storage volumes are encrypted with AES-256 via the cloud provider's managed encryption (Neon uses AWS-managed keys backed by AWS KMS). Backups inherit the same encryption.
• At rest (logs & secrets) — Vercel-encrypted environment variables hold API keys and signing secrets; nothing sensitive is committed to source control. Local development uses separate, non-production credentials.
• Passwords — recruiter passwords are stored as bcrypt hashes with a per-user salt; we never see or store the plaintext.

Voice audio is the most sensitive part of an interview and we treat it as intentionally ephemeral. We do not produce a downloadable recording, we do not persist audio to our database, and we do not ship audio to long-term object storage.

• The candidate's microphone stream is sent to LiveKit Cloud over an encrypted WebRTC connection (DTLS-SRTP, AES-128-GCM).
• LiveKit forwards the stream to a speech-to-text provider (Deepgram via LiveKit Inference) in real time. STT processes audio in volatile memory and returns text turns; those turns are sent to the LLM and persisted as the transcript.
• Audio is held only in the volatile buffers required to transport and transcribe each turn (single-digit seconds in flight). When the interview room ends, those buffers are released and the underlying connection terminates.
• We do not write interview audio to our database, to object storage, to backups, or to any long-term log. There is no audio file to export or subpoena.

If a future feature requires retaining audio (for example, opt-in recording for quality review or candidate verification), we will update this document and require explicit recruiter and candidate consent in the UI before turning it on.

• Application access — recruiters see only their own organization's jobs, candidates, transcripts, and reports. Role-based permissions inside an organization limit who can invite candidates, view reports, or change settings.
• Engineering access — production database and infrastructure access is limited to a small number of named engineers, gated by SSO and hardware-backed multi-factor authentication (WebAuthn / FIDO2). Console access to Neon, LiveKit, Vercel, and the email provider is granted on the same basis.
• Least privilege — Neon and LiveKit credentials are scoped to the minimum permissions a given service needs. Read-only roles are used wherever possible. Long-lived static tokens are rotated at least every 90 days; short-lived signed tokens are preferred where supported.
• Auditing — administrative actions on Neon, LiveKit, and Vercel are logged by those providers and retained for at least 90 days. We review the active access list quarterly and revoke unused credentials.
• Offboarding — when a team member leaves, their SSO is revoked and any personal API tokens are rotated within 24 hours.

Concrete retention windows by category. See Data inventory for the at-a-glance table and Deletion process for how to trigger early deletion.

• Transcripts and AI reports — retained for as long as the recruiter keeps them, so hiring teams can revisit results across an open requisition. Recruiters can delete individual sessions at any time from the dashboard.
• Account closure — when an organization closes its account, data enters a 90-day grace window during which it can be restored on request. After day 90, primary records are hard-deleted.
• Database backups — Neon point-in-time recovery (PITR) covers the previous 7 days on our current plan (extendable to 30 days for enterprise). Data deleted from the primary database is purged from PITR history within that window as the window rolls forward.
• Operational logs — Vercel runtime logs, LiveKit session events, and application audit logs are retained for up to 30 days for debugging and abuse investigation, then rotated.
• Email delivery records — Resend retains transactional email metadata (recipient, subject, status) for 30 days.
• Voice audio — not retained beyond the active room (see Voice audio).

Backups exist to recover from operational failure, not to extend retention. They inherit the encryption and access controls of the primary database and are not browsable by humans except during a declared incident.

• Backup method — Neon provides continuous Postgres write-ahead-log (WAL) shipping plus point-in-time recovery (PITR). There is no separate nightly dump on our side; the PITR window is the backup.
• PITR window — 7 days on the current plan, with second- level granularity. Enterprise plans can extend this to 30 days.
• Recovery Point Objective (RPO) — target ≤ 1 minute of data loss for a hard database failure, bounded by Neon's WAL replication lag.
• Recovery Time Objective (RTO) — target ≤ 4 hours to restore a fully functioning environment from a known-good PITR target, including schema verification and service smoke tests.
• Restore testing — we test a representative PITR restore into a non-production branch at least quarterly and document the result. Vercel and LiveKit recoveries depend on those providers; we track their published RPO/RTO commitments and status pages.
• Voice audio — not in backup scope because it is never persisted.

Recruiters can delete individual interview sessions and their associated transcripts and reports from inside the dashboard. Deletion is immediate for the primary database and propagates out of backups on the PITR schedule described in Backups and recovery.

• Per-session deletion — open a session in the dashboard and use the delete action. The row is removed from Postgres immediately; the deletion ages out of the PITR window within 7 days.
• Account-wide deletion — to delete an entire organization's data, email hello@nexprove.com from an admin address. We confirm the request, then schedule the hard delete. Target completion is within 30 days of the confirmed request, with PITR aging out within 7 days after that.
• Candidate requests — candidates can ask the recruiter who invited them to delete their interview, or contact us directly. We will route the request to the controlling recruiter and confirm in writing when the data is removed, typically within 30 days.
• Subprocessor propagation — for subprocessors that do not retain interview content (LiveKit, Deepgram, Gemini, Cartesia in our configured mode), deletion is automatic with session end. For those that do retain metadata (Vercel logs, Resend), deletion follows their published retention windows.

We use the following subprocessors to deliver the service. Each is bound by its own security commitments and data processing terms. We will give existing customers notice before adding a new subprocessor that handles interview content.

Our internal targets for confirmed security incidents are below. Targets start the clock from the first detectable signal (monitoring alert, on-call page, or subprocessor notification), not from the moment of first compromise.

• Triage — engage on-call within 30 minutes of the first signal and classify severity within 2 hours.
• Containment — rotate affected credentials, isolate impacted systems, and halt suspicious sessions within 4 hours of confirmation.
• Investigation — preserve logs, identify scope of affected data and customers, and confirm whether interview content was accessed.
• Notification — notify affected recruiters within 72 hours of confirmation, with the facts available at the time, the data categories involved, and the steps we are taking. Where the GDPR or a comparable regime applies, regulator notification follows the same window.
• Post-incident review — publish a written summary to affected customers within 30 days, including root cause and the changes we are making to prevent recurrence.

To report a suspected vulnerability or incident, email security@nexprove.com or see the vulnerability disclosure guidance on the Support page.

We are an early-stage product and do not yet hold an independent attestation in our own name. We are honest about that and design around it rather than overclaim.

• Subprocessor attestations — our core infrastructure subprocessors (Vercel, Neon, LiveKit, Google, Deepgram) operate under SOC 2 Type II programs and several hold ISO 27001 certification. Reports are available directly from each vendor under NDA. Where customers ask about HIPAA or GDPR posture, we point to the specific subprocessor commitments and our own DPA.
• Internal controls — we follow the SOC 2 trust criteria internally (access control, change management, encryption, monitoring, incident response) so that an external audit is a documentation exercise rather than a re-platforming exercise.
• Penetration testing — an annual third-party penetration test is planned as we scale beyond pilot customers. Today we rely on the subprocessor-tested infrastructure underneath us, automated dependency scanning (Dependabot, npm audit, GitHub code scanning), and pre-deploy review on every change. A summary of the first external test will be made available to enterprise customers under NDA once complete.
• Vulnerability disclosure — security researchers can report findings to security@nexprove.com. Our full policy, scope, and safe-harbor language live on the Support page.
• Roadmap — we intend to pursue a SOC 2 Type II attestation in our own name as we scale and will update this page when that engagement begins. Enterprise customers can request a current security questionnaire and subprocessor list through their account contact.