The Legal AI Security Checklist: What to Ask Before Your Firm Adopts Any AI Tool

Is data encrypted in transit and at rest? What encryption standards are used?

TLS 1.2+ for transit and AES-256 for storage are table stakes. Ask specifically whether data is encrypted at the application layer or only at the infrastructure layer. Application-layer encryption means the vendor's own engineers cannot read your data without additional access controls. Infrastructure-layer encryption only protects against physical theft of hardware.

Where are prompts and responses stored, and for how long?

Many AI platforms log every interaction for debugging, quality assurance, or abuse detection. Ask whether logs include the full text of prompts and responses. Request the retention schedule in writing. Some vendors retain interaction logs for 30 days; others retain them indefinitely. For privileged communications, shorter retention with verifiable deletion is strongly preferable.

Does the vendor use subprocessors, and do they have access to your data?

Most AI vendors rely on cloud infrastructure providers (AWS, Azure, Google Cloud) and may use additional subprocessors for specific functions. Request a complete subprocessor list and understand what data each subprocessor can access. Your vendor contract is only as strong as the weakest link in their supply chain.

Can you get a data processing agreement (DPA) that specifies data handling obligations?

A DPA should specify data categories processed, processing purposes, retention periods, deletion procedures, subprocessor notification requirements, and breach notification timelines. If a vendor will not execute a DPA, that is a significant red flag for any firm handling confidential client data.

What happens to your data if you terminate the relationship?

Request contractual guarantees for data return and certified deletion upon termination. Ask how long deletion takes and whether backups are included. Some vendors retain backup copies for 90 days or more after account termination — during which your client data remains in their systems.

Does the vendor use customer inputs to train, fine-tune, or improve its AI models?

This is a binary question that demands a binary answer. 'We may use anonymized data to improve our services' is not acceptable — anonymization of legal text is unreliable, and even anonymized case details can be identifying. The answer must be an unambiguous no, backed by contractual language. Check the vendor's general terms of service separately from any enterprise agreement, as they may differ.

Does the vendor distinguish between model training and other data uses like safety monitoring?

Some vendors do not train on customer data but do use it for abuse detection, content filtering, or safety evaluations that may involve human review. Understand exactly what human review means: who reviews data, under what circumstances, and what confidentiality obligations those reviewers have. Safety monitoring that involves human review of privileged content raises the same concerns as model training.

Are training opt-out policies contractual commitments or just current practices?

A vendor's privacy page may say they do not train on enterprise customer data, but if this is not in your contract, it can change with a terms-of-service update. Ensure the no-training commitment is in a signed agreement with breach remedies, not just a blog post or FAQ.

What happens to data in the model's context window? Is it persisted beyond the session?

Understand the difference between data used in a conversation context (which should be ephemeral) and data stored in the vendor's systems. Some platforms offer persistent memory features that retain information across sessions. If your attorneys use such features with client data, that data is stored in the vendor's systems in a form designed to be recalled — which has very different risk implications than ephemeral processing.

SOC 2 Type II

Verifies that a vendor's controls are designed effectively AND have operated effectively over a period (typically 6-12 months). Covers five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Type II is significantly more meaningful than Type I, which only confirms controls exist at a point in time.

limitation: SOC 2 is a US-focused attestation, not a certification. The scope is defined by the vendor — a narrow scope can exclude the systems that actually process your data. Always request the full SOC 2 report (not just the certification letter) and verify that the systems described match the ones handling your firm's data.

ISO 27001

An international standard for information security management systems (ISMS). Requires a comprehensive risk assessment and documented controls across 93 control objectives. More prescriptive than SOC 2 about what must be addressed. Preferred by international firms and required by many European clients.

limitation: ISO 27001 certifies the management system, not the specific security of a product. A vendor can be ISO 27001 certified while the specific product you use operates outside the certified scope. Ask whether the certification scope includes the specific services and data centers that will handle your data.

HIPAA Compliance

Required if the AI tool will process protected health information (PHI) — common for firms with healthcare clients, personal injury practices, or benefits work. The vendor must sign a Business Associate Agreement (BAA) and meet specific safeguards for PHI.

limitation: There is no official HIPAA certification. Vendors claiming to be 'HIPAA certified' are using marketing language. What matters is whether they will sign a BAA and whether their controls satisfy the Security Rule's technical safeguards. Ask for their most recent HIPAA risk assessment.

FedRAMP Authorization

Required for AI tools used in matters involving federal government data. Demonstrates rigorous security evaluation by a Third-Party Assessment Organization (3PAO). Relevant for firms with government contracts or regulatory practice areas.

limitation: FedRAMP authorization is expensive and time-consuming, so many legal AI startups do not have it. If your firm handles federal government work, this gap may limit which AI tools you can use for those matters.

In which countries or regions is data stored and processed?

AI workloads often run in specific cloud regions based on GPU availability, not customer preference. A vendor may store your data in the US but process it through GPU clusters in another region. Ask about both storage and processing locations. For GDPR-subject data, processing outside the EEA requires specific legal mechanisms like Standard Contractual Clauses.

Can the firm select or restrict data residency to specific regions?

Some enterprise AI vendors offer data residency controls that let you specify where your data is stored and processed. This is particularly important for firms handling EU client matters, Canadian privacy-regulated data, or work subject to data localization laws in jurisdictions like China, Russia, or India.

How does the vendor handle cross-border data transfers?

After the Schrems II decision invalidated the EU-US Privacy Shield, cross-border transfers require alternative mechanisms. The EU-US Data Privacy Framework (DPF) now provides one path, but the vendor must be certified. Standard Contractual Clauses remain the most common mechanism. Ask whether the vendor has conducted a Transfer Impact Assessment for relevant jurisdictions.

Is the vendor subject to laws that could compel data disclosure?

The US CLOUD Act allows US authorities to compel disclosure of data stored abroad by US-headquartered companies. If your firm handles matters adverse to US government interests, this may be relevant. Similarly, the Chinese Cybersecurity Law and National Security Law impose broad disclosure obligations on companies operating in China.

1. Do you train your AI models on customer data, including prompts, uploaded documents, or generated outputs?

The only acceptable answer is an unqualified 'no' backed by contractual language. 'Not currently' or 'only in anonymized form' are not sufficient. Obtain a written commitment in the master services agreement, not just a marketing FAQ.

2. Can you provide your current SOC 2 Type II report covering the systems that will handle our data?

Request the full report, not a summary letter. Verify the scope includes the specific product and infrastructure your firm will use. Check the testing period — a report from 18 months ago may not reflect current controls. If the vendor only has SOC 2 Type I, ask when Type II will be available.

3. Where is our data stored and processed, and can we restrict it to specific regions?

Get specific data center locations, not just cloud provider names. Confirm that both storage and GPU processing stay within your required jurisdictions. If the vendor cannot offer data residency guarantees, assess whether this is acceptable given your client base and regulatory obligations.

4. What is your data retention policy, and can we configure shorter retention windows?

Understand what is retained (prompts, outputs, metadata, logs), for how long, and whether retention is configurable per customer. Shorter retention reduces risk. Ask whether backups follow the same retention schedule or persist longer.

5. Do you support SSO via SAML 2.0 or OpenID Connect, and is MFA enforced?

SSO integration with your identity provider is essential for centralized access management. MFA must be required, not optional. Ask about support for conditional access policies, device trust, and session management.

6. What audit logging is available, and can we export logs to our SIEM?

Logs should capture user identity, timestamp, action type, and data accessed. Real-time log streaming to your Security Information and Event Management (SIEM) system enables proactive threat detection. If the vendor only provides basic usage dashboards without exportable audit logs, their platform is not enterprise-ready.

7. Who at your organization can access our data, and under what circumstances?

Understand the vendor's internal access controls. Support engineers, safety reviewers, and developers may have varying levels of access. Ask about background checks, confidentiality agreements, and access approval processes. Zero-trust architecture where no employee can access customer data without specific authorization and logging is the gold standard.

8. What is your breach notification timeline, and what information will you provide?

Your firm's ethical obligations may require faster notification than the vendor's standard timeline. A 72-hour notification window (matching GDPR requirements) is a reasonable expectation. The notification should include what data was affected, when the breach occurred, and what remediation steps are being taken.

9. Will you sign a Data Processing Agreement (DPA) and, if applicable, a Business Associate Agreement (BAA)?

A DPA should specify processing purposes, data categories, subprocessor obligations, and deletion requirements. A BAA is required if any protected health information will be processed. Vendors that refuse to sign these agreements are not suitable for law firm use.

10. What is your incident response plan, and when was it last tested?

Ask for a summary of the vendor's incident response procedures and the date of their last tabletop exercise or simulation. A plan that has never been tested is not a plan — it is a document. Look for vendors that conduct annual or more frequent incident response exercises.