How to Vet a Legal Tech Vendor's Security Claims

“Bank-grade encryption” and “security is our highest priority” are not answers. They are invitations to ask better questions.

You do not need to be a security engineer to conduct a useful vendor review. You need a written record of what the provider does, what the contract promises, what the product lets the firm configure, and what remains the firm’s responsibility.

1. Follow the data

Start with a simple diagram or list. What information enters the product? Where is it stored and processed? Which integrations, analytics services, support tools, AI providers, and other subprocessors receive it?

Ask:

• which countries host or process customer information;
• which employees and contractors can access content;
• how access is approved and logged;
• whether support staff can impersonate a user;
• what metadata is collected; and
• whether the firm can disable optional data sharing.

A public subprocessor list is useful. Save a copy and find out how the firm will be notified when it changes.

2. Ask who holds the encryption keys

Encryption in transit and at rest should be baseline controls for a service holding client information. They do not tell you whether the provider can read the content.

If the provider controls the keys, its application can usually decrypt data to deliver features such as search, previews, processing, support, or AI analysis. That may be a reasonable tradeoff, but the firm should know it is making one.

If the vendor claims end-to-end encryption, ask what is excluded. File names, folder structures, search indexes, logs, backups, previews, and integration data may receive different treatment. Ask how key recovery works and whether a provider-held recovery path defeats the claim.

3. Read audit reports with their scope in mind

A SOC 2 report can show that an independent auditor examined stated controls. Ask whether it is Type I, a design assessment at a point in time, or Type II, which examines operation over a period. Check the dates, systems in scope, exceptions, and complementary controls assigned to customers.

The report does not prove that the product has no vulnerabilities. It also does not decide whether the firm’s use is ethical, whether the contract permits broad data use, or whether encryption is end-to-end.

Other useful evidence may include penetration-test summaries, vulnerability management, secure-development practices, incident exercises, and a current security contact. Small providers may not have every formal certification. If so, they should still give concrete, candid answers.

4. Review the contract, not only the security page

Look for terms covering:

• confidentiality and permitted use of customer content;
• AI or model training;
• security obligations and changes;
• breach notification timing and cooperation;
• subprocessors;
• government and civil legal demands;
• retention and backup deletion;
• data return after termination; and
• unilateral amendments.

Watch for a content license broader than the rights needed to operate the service. “We do not sell data” is not the same as “we do not use client material to train or improve models.”

If an important promise appears only in a sales email, ask to put it in the agreement.

5. Plan for failure on both sides

Ask the vendor how it detects, contains, and communicates incidents. Find out whether the firm can obtain relevant logs, revoke all sessions, freeze an account, or export information during a dispute.

Then check the controls the provider expects the firm to operate. These often include MFA, device security, permission reviews, administrator separation, backups, and timely removal of users. A strong vendor cannot compensate for a shared password or a compromised email account that can reset access.

6. Test data portability

Export is part of security and continuity. Run a sample rather than accepting “your data is always yours.”

Confirm that the firm can retrieve original documents, contacts, matters, notes, tasks, communications, custom fields, financial records, and the identifiers connecting them. Ask whether cancellation changes access immediately, how long downloads remain available, and when live and backup copies are deleted.

Products are repriced, redesigned, acquired, and discontinued. A usable exit reduces the harm from any of those events.

7. Turn the answers into a decision

The review should identify:

• the information and matters approved for the tool;
• safeguards the firm must configure;
• uses that remain prohibited;
• any client consent or instruction that applies;
• the person responsible for annual review; and
• the event that would trigger an earlier review.

A refusal to answer a material question is information. So is a clear “we can read the data, and these controls govern access.” Precision deserves more trust than a grand promise.

How we expect to be judged

Usus is being built as a local-first system with optional encrypted synchronization. That does not exempt us from this checklist. Before release, firms should expect documentation of what stays on the device, what synchronization exposes, who holds keys, which metadata remains visible, how recovery works, and how all data can be exported.

Architecture matters. Verifiable details matter more.