PrimaryCheck
Trust and security

Security practices, stated as they stand

Verification data is a consumer report about a real person. This page lists the controls that protect it today, the audits that are in progress, and who processes the data. Nothing is claimed before it is true; the compliance page covers the FCRA program itself.
Status

In place, in progress, planned.

Each item is marked. Audit evidence and the controls matrix are shared with customers under NDA.
SOC 2
Type II in progress; the observation window has not closed and no report exists yet. Date to be announced. No SOC 2 attestation is claimed on this site or in any proposal until the report is issued.
Data location
Google Cloud, us-east1 (South Carolina, United States). The API, workers, database, evidence storage and datasets all run in that region; nothing is replicated outside it.
Subprocessors
Google Cloud (hosting, database, storage, queues, secrets), Vercel (website and dashboard hosting), SendGrid (transactional email: magic links, invites, consumer notices). No other party receives subject data.
Identifiers
No Social Security numbers are collected or stored. Verification runs on name, date of birth and credential identifiers.
Retention
Reports, evidence and consents are kept seven years, then purged by a nightly job whose runs are logged; on-demand erasure redacts a person earlier while the audit skeleton stays.
Availability
99.9% monthly target on the API; per-source health is published on the status page, never hidden in an aggregate.
Controls in place

What protects the data today

01
Encryption in transit

TLS on every connection: the API and sandbox on Cloud Run, the website on Vercel, and every call we make to a primary source. Webhooks are sent only to the HTTPS or HTTP URL you register, signed either way.

02
Encryption at rest

Cloud SQL, Cloud Storage evidence blobs and the dataset volume are encrypted at rest by Google Cloud. Webhook signing secrets are additionally encrypted in the application (Fernet) with a key that lives only in Secret Manager; API keys and session tokens are stored only as SHA-256 hashes.

03
Secrets never in images

Database URLs, signing keys and vendor credentials come from Secret Manager at runtime with per-service-account access; the container image is secret-free and the repository holds no credentials.

04
Signed webhooks

Every delivery carries PrimaryCheck-Signature: a timestamp and an HMAC-SHA256 of the body under your endpoint's secret, shown once at creation. Replays older than five minutes are rejected by the SDK helpers.

05
Hashed API keys and sessions

Keys are shown once and stored as hashes; the dashboard signs in by single-use magic link and 30-day sessions that are revoked on sign-out or removal from the team. Per-key and per-account rate limits apply.

06
Role-based team access

Owner, admin, member and viewer roles per account; viewers can read but change nothing, only owners and admins mint live keys, and the last owner cannot be removed.

07
Per-account isolation

Every query is scoped by account id; a verification, evidence file or monitor from another account answers 404, never a different customer's record.

08
Append-only audit log

Every order, cancel, erasure, notice, consent, key and team change is written with the actor, the IP and the time. GET /v1/account/audit exports it; entries are never edited.

09
Evidence integrity and signed links

Every source payload and page capture carries a SHA-256 of exactly the bytes we hold. Downloads use 15-minute signed links, so an auditor can be handed a link without an API key.

10
Retention and erasure

A nightly purge enforces the seven-year schedule and logs each run. POST /v1/verifications/{id}/erase redacts a person on request and keeps the FCRA audit skeleton.

11
Source politeness and health

Each primary source has its own concurrency and rate budget; nightly canaries re-check known-good records and degrade a failing source before customers see a wrong answer.

12
Internal task routes

Worker and scheduler calls between services are authenticated with Google OIDC tokens for dedicated service accounts; ops endpoints need an ops-role session on a staff account.

In progress

Audits and attestations

Stated as they stand. A status changes here on the day the evidence exists, not before.
ItemStatusNotes
SOC 2 Type IIin progressDate to be announced. Controls operate today; the audit window is open. No report, no claim.
PBSA accreditationin progressApplication follows the required operating history.
E&O and cyber insurancein progressBound before the first live customer; certificates on request after binding.
Penetration testplannedScheduled with the SOC 2 window; summary available to customers under NDA once complete.
NCQA CVO certificationplannedFor health-plan and hospital credentialing customers.
Reporting

Security questions and disclosures

Questionnaires, the controls matrix and audit evidence are answered under NDA.
  • Security questions and vendor questionnaires: security@primarycheck.com.
  • Report a vulnerability to the same address; we acknowledge within two business days and do not pursue good-faith researchers.
  • Subject data requests (file copies, disputes, erasure under a state privacy law) go through the consumer portal or consumers@primarycheck.com; customers erase their own orders with the erase endpoints.
  • Incidents affecting a source are reported per source on the status page; incidents affecting customer data are notified to the account owner by email.

Need the controls matrix?

Policies, the controls matrix and audit evidence are shared with customers under NDA.