Security

Everything we do to keep your data safe.

Verinode holds the operating data of restoration businesses, so the security of that data is the product. This page documents the controls we run, grouped the way an auditor reads them, with the matching ISO 27001 Annex A references. Our program is built around those standards.

We are honest about status: we are not yet certified against either. SOC 2 and ISO 27001 are third-party attestations, not badges a company awards itself, and a SOC 2 Type II audit is planned. What follows is exactly what we do today, plus what we have not done yet.

SOC 2 Type IIPlannedISO/IEC 27001PlannedInfrastructureCertified

Last updated: July 2026

The control program

Security

The core of the program: keep operator data readable only by the operator it belongs to and the product working on their behalf, and nobody else.

Per-operator encryption
Identifying fields are encrypted with AES-256-GCM under a three-key envelope: a Vault Key scoped to each operator and issued at signup, the operator's own password, and a server root key held outside the database. No single key, and no database dump on its own, yields plaintext.
Database-level access control
Row Level Security is enabled on every table and denies by default. Application access runs through scoped, service-role clients; the browser never queries the database directly.
Tenant isolation
Operator business data and the shared intelligence layer are two physically separate databases with separate credentials; no query crosses that boundary. The operator database is region-deployable.
Multi-factor authentication
Accounts support a time-based one-time-password second factor, and sensitive actions can require a verified second factor before they run, not only at login.
Encryption in transit
All traffic is served over TLS.
Key and secret management
Encryption keys are managed outside application code, and root key material is escrowed under a documented recovery runbook.
Enterprise authentication
Single sign-on over SAML 2.0 and OIDC, plus SCIM directory provisioning, for members who require it.
Least-privilege access
Production data access is limited to a small, named set of administrators, and every access is logged. A small team means a small blast radius.

SOC 2 Security (CC6, CC7) · ISO 27001 Annex A: A.5.15 to A.5.18, A.8.2 to A.8.5, A.8.24

Confidentiality

The commitments that make the benchmarks worth trusting: your data works for you, and the network never learns which numbers are yours.

Never provided to carriers
Written into the Terms and the Data Use Policy: operator data is never provided to insurance carriers, TPAs, or competitors in identifiable form.
Anonymization before pooling
Contributions are stripped of identifiers and passed through a keyed hash before they enter the intelligence layer, so a benchmark number cannot be traced back to a business.
Minimum cohort size
A benchmark is only published once its peer group is large enough that no single business can be singled out.
No training on your data
LLM providers process content under no-training terms, and PII fields are replaced with typed placeholders before any text is transmitted.

SOC 2 Confidentiality (C1) · ISO 27001 Annex A: A.8.10, A.8.11, A.8.12

Availability

Keeping the product up, the data recoverable, and problems visible before they are felt.

Backed-up, managed database
Managed Postgres with automated backups and point-in-time recovery, on each of the two isolated databases independently.
An off-site copy we cannot lose with the account
Automated backups and point-in-time recovery all live inside the database vendor's account, so a problem with that one account could reach the original and every copy at once. Once a week both databases are also exported to a separate storage vendor, in a separate account, in a different country, on infrastructure that shares nothing with the systems that run the product. The export is encrypted before it leaves our control: the storage vendor holds ciphertext and never holds the key, and the job that writes the backup carries only the public half of the key, so it produces backups it cannot itself read. Retention is 90 days, which is what keeps the erasure window in our Data Use Policy true. The most recent export has been re-downloaded, checksummed, and decrypted end to end, then restored into a clean database to confirm it loads with every record intact. That restore drill established one practical requirement, that the recovery target be provisioned the way our platform is rather than a bare database, which is now documented. A full drill into a fresh live environment, with formally measured recovery-time and recovery-point figures, is the remaining step before we would call this fully tested disaster recovery.
Resilient hosting
Serverless, multi-region application hosting on managed infrastructure.
Continuous monitoring
An automated sentinel checks environment configuration, background jobs, provider health, and the encryption cache every twenty minutes and alerts on regression.
Public status page
Uptime and incidents are reported at status.verinode.ai, linked from operator-facing surfaces.

SOC 2 Availability (A1) · ISO 27001 Annex A: A.8.13, A.8.14, A.8.16, A.5.30

Processing Integrity

Making sure data that flows in is written correctly, and that changes to the system are controlled.

Schema-enforced ingestion
Every extracted record passes through a single normalization layer validated against a committed snapshot of the live schema, so malformed or unexpected data is rejected or quarantined rather than written silently.
Extraction quality checks
A daily canary scores the extraction pipeline against fixed fixtures and alerts on quality regression.
Gated change management
Schema, migration, security, and anonymization checks run automatically before every deploy and block releases that fail.
Audited, append-only logging
Data access and every decryption are written to an audit trail retained outside the application's own environment, so it cannot be quietly rewritten.

SOC 2 Processing Integrity (PI1) · ISO 27001 Annex A: A.8.15, A.8.16, A.8.28, A.8.32

AI Governance and Safety

Verinode is an AI product, so the safeguards that matter most are the ones that do not depend on a model behaving. The controls that would cause real harm if a model were wrong are enforced in code, not left to a prompt.

Deterministic guardrails, not prompt trust
Anything that would be a real harm if a model were wrong, a cross-tenant read or a data mutation, is enforced deterministically: row-level security, k-anonymity gates on every benchmark, and human confirmation on every mutation sit below the model.
Numerical grounding
Agents may not state a figure that is not traceable to a real data lookup. Un-sourced numbers are refused rather than guessed.
Adversarial evaluation
A daily evaluation runs a corpus of prompt-injection and misuse attempts against the agents, with a P0 alert on any critical breach, alongside a benign corpus that guards against over-refusal.
Advisory-only authority
No agent can bind the operator or Verinode to anything. An agent recommends; the operator decides, and nothing takes effect until the operator accepts it.
Version-pinned safety baseline
Every model call routes through a shared safety baseline that domain prompts and ingested content cannot override, and the baseline version is logged with every call so any output traces back to the rules that produced it.

SOC 2 Security and Processing Integrity (CC7, PI1) · ISO 27001 Annex A: A.5.24, A.8.16, A.8.28, A.8.29

Privacy

Your rights over your data, documented and exercisable without asking permission.

Published privacy notice
What we collect, why, and the legal basis are set out in the Privacy Notice.
Data-subject rights
A signed-in operator can pull a complete, self-serve export of their own data, including full consent history, without routing through support. Correction and deletion follow a documented procedure.
Data minimization and ownership
We collect what the product needs, and ownership of the underlying records stays with the operator.
Subprocessor transparency
Every third party that processes data on our behalf is listed publicly, with its purpose, data, location, and safeguards, and members are notified of changes.

SOC 2 Privacy (P1 to P8) · ISO 27001 Annex A: A.5.34 · GDPR Articles 15 to 22 and 28

Certifications and roadmap

SOC 2 Type IIPlanned
Not yet certified. The control program above is designed around the Trust Services Criteria. When the audit observation window opens, we will say so here.
ISO/IEC 27001Planned
Not yet certified. The controls above map to Annex A, referenced under each domain. Certification will follow the SOC 2 work.
InfrastructureCertified
The subprocessors that host and process data on our behalf hold their own SOC 2 Type 2 and ISO 27001 attestations. Each is listed, with its safeguards, on the Subprocessors page.

What we have not done yet

The honest other half of the list. Security you can verify is worth more than security you have to take on faith, so this is where we would rather under-claim.

  • ·We are not SOC 2 or ISO 27001 certified. A company that is not audited cannot truthfully say it is SOC 2, and we would rather be precise than borrow the claim.
  • ·Independent penetration testing by an external firm is planned alongside the SOC 2 audit, not yet completed.
  • ·Formal, third-party-attested management-system documentation is being built toward the audit, rather than finished today.
  • ·Operator-only key custody, where not even our own systems can read a slice, is on the roadmap. Today our automated systems decrypt data under an audited background key so your Co-COO can work while you sleep, with every access logged.

The detailed control matrix

The full matrix, every control above mapped to its SOC 2 Trust Services Criteria and ISO 27001 Annex A reference with the evidence behind it, is available under NDA to members and prospective members in active evaluation, including as part of a vendor security review. Request it at [email protected].

Related

Contact

Security questions, control-matrix requests, and vulnerability disclosures: [email protected]. Data-subject and privacy requests: [email protected].

This page describes controls in place as of the revision date above and is updated as the program matures. It is a description of our security posture, not a warranty or a substitute for the SOC 2 report it anticipates.