How your data is protected.

Three protections, one for each part of the question. What stops it from being seen: identifying columns are encrypted with a Vault Key that belongs to the operator and is never stored on Verinode infrastructure in plaintext, so Verinode cannot read those records even with full database access. What stops it from being sold: the data-use policy, codified in the Terms of Service, commits that operator data is never sold to insurance carriers, and benchmark data is hashed and held to a minimum cohort size before publication. What stops it from being stolen: row-level security is enforced at the database layer, and identifying records stay unreadable in a breach without an authenticated operator session.

The Vault Key is the encryption key that protects an operator's identifying records: customer details, claim numbers, team identities, adjuster and vendor contacts, vehicle and equipment identifiers, certification numbers, facility addresses, and free-text narratives across incidents, supplements, fleet accidents, leases, and decision plans.

It belongs to the operator and is never stored on Verinode infrastructure in plaintext. Decryption requires the operator's authenticated session. There is no path from a browser session, a public API, or a Verinode engineer with admin credentials to operator identifying data. The architecture enforces this before any contract has to.

SOC 2 is real and important, but it is not the question to ask first. SOC 2 audits the controls a vendor has in place to protect customer data: who can access it, how access is logged, how incidents are handled. It does not audit what the vendor is allowed to do with the data, who they share it with, or what they monetize from it.

The question to ask first is who holds the encryption keys. If the vendor encrypts your data at rest but holds the keys, the vendor and any process it runs can decrypt and use it. That satisfies SOC 2 and most regulatory frameworks, and it does not stop the vendor from training models on your data or building benchmarks it sells to other customers. Verinode is built on the inverse pattern: identifying data is encrypted under a key the operator holds, so Verinode cannot read it.

Three separate database layers, each with its own trust boundary. A core layer handles operator routing, memberships, and group structure. A separate PII layer holds each operator's business data and is isolated from the broader network, with architecture that supports regional deployment for data-residency requirements. A separate intelligence layer holds anonymized benchmarks and vendor-catalog data.

When data flows from the PII layer to the cross-operator benchmark layer, the operator identifier is hashed first, and a cohort floor applies before anything is published. No individual operator is identifiable in the intelligence layer.

No. The commitment that operator data is never sold to insurance carriers is codified in the data-use policy and the Terms of Service, and reinforced by the Operator Advisory Council, which is restricted to active operator individuals and excludes any carrier or TPA representative. The independence claim is the product. An operator-side trust that sold to the other side would have no operators left.

Yes. Operators can request a full export of their data at any time, and the data-use policy and privacy notice describe how deletion and data-subject requests are handled. Ownership of the underlying records stays with the operator.