Data rooms contain pre-announcement M&A information. When a legal team uploads a data room to an external vendor's processing environment, they are moving the most sensitive documents in the transaction — target company financial records, personnel information, IP portfolios, strategic plans — outside the perimeter of their own systems. The security requirements for that vendor relationship are correspondingly serious.
This is a practical checklist for what to require from AI vendors in the M&A diligence context. It's organized around the questions that corporate legal and IT security teams most frequently ask during vendor evaluation. It is not legal advice, and it is not a substitute for your organization's own vendor security review process.
1. Document isolation: per-deal or shared environment?
The first and most critical question: are your documents processed in an environment isolated from other clients' engagements, or are they processed in a shared multi-tenant environment?
In a shared environment, a configuration error, a software bug, or a security incident affecting any engagement could potentially expose another engagement's documents. For routine SaaS applications, shared infrastructure is standard and acceptable. For M&A data rooms containing pre-announcement deal information, the risk profile is different. A data cross-contamination incident in M&A context is not just a security failure — it's a potential securities law problem.
What to require: per-engagement processing isolation, with architectural separation (not just access control) between engagements. The vendor should be able to describe the isolation mechanism — separate compute environments, separate storage namespaces, or equivalent — not just assert that isolation exists.
2. Data retention: who decides, and when is deletion guaranteed?
Document retention policy determines how long your data room documents remain in the vendor's systems after the engagement ends. The risk window is the gap between when the engagement is complete and when deletion occurs — documents sitting in a vendor's storage after the deal closes are still exposed to any security incident that affects that vendor.
What to require: a clear default retention policy, the ability to specify deletion timing, and a mechanism for confirming deletion. "We delete on request" is not a retention policy. "Documents are deleted within 24 hours of memo delivery confirmation unless extended retention is requested in writing" is a retention policy.
Extended retention — keeping documents post-close for reference — is sometimes requested by deal teams who want to access the original extraction corpus after closing. If you need this, confirm that it's available under a separate written arrangement with explicit security obligations. Extended retention for post-close reference is architecturally distinct from the standard engagement model and should be treated as a separate commitment.
3. Access controls: who at the vendor can see your documents?
Processing architecture and human access are different questions. A vendor can have strong technical isolation between engagements but still allow broad internal access to document content by personnel with administrative rights.
What to require: documentation of who, by role and access level, can access deal document content — not just the engagement metadata, but the actual documents. The answer should be: no routine access by any vendor personnel to document content; administrative access to infrastructure (not content) restricted by role and logged; any access to document content for support or debugging purposes requires documented authorization and generates an audit log.
Vendors who cannot answer this question specifically, or who answer with "our team is trustworthy," haven't built their access control architecture for M&A context.
4. Model training: are your documents used to train the extraction model?
This question has become standard in AI vendor evaluations, and it's particularly important in M&A context. If the vendor's extraction model is trained or fine-tuned on client documents — including your data room — then deal information you upload may persist in the model's weights indefinitely, even after your documents are deleted from storage.
What to require: a clear commitment that client documents are not used for model training or fine-tuning, and that this applies retroactively — documents processed before the commitment was in place are not included in training datasets. This should be in the NDA or data processing agreement, not just in the vendor's marketing materials.
5. Encryption: at rest and in transit, with key management details
Encryption is table stakes, not a differentiator. What matters is the specifics: what encryption standard (AES-256 at rest, TLS 1.3 in transit are the current minimums), how encryption keys are managed, and whether key rotation is per-engagement or periodic.
Per-engagement key rotation — generating a new encryption key for each engagement and rotating or deleting it when the engagement ends — provides stronger isolation than periodic rotation. If a key from a previous engagement is compromised after that engagement has ended, per-engagement key rotation limits the exposure to that engagement's documents, not all documents processed with the same key.
6. NDA as standard practice, not an accommodation
Any vendor processing M&A data room documents should sign a mutual NDA as a standard term of the engagement, not as a special accommodation. The NDA should cover: the confidentiality of deal documents and deal information, restrictions on use of deal information outside the engagement scope, notification obligations in the event of a security incident affecting deal information, and obligations that survive termination of the engagement.
If a vendor treats NDA execution as non-standard or raises objections to mutual confidentiality obligations, that is a vendor evaluation signal, not a starting negotiating position.
The evaluation conversation
The right way to run this evaluation is to treat it as a security review conversation, not a sales conversation. Ask for the architecture documentation, not the marketing deck. Ask for a written response to specific questions, not verbal representations. If the vendor has gone through client security reviews before — which any vendor with corporate legal clients should have — they will have documentation ready. If they haven't, that's also a signal.
Security review takes time, and that's appropriate. Running this review before you have a deal on the table — as part of an approved vendor evaluation process — is easier than running it under deadline pressure when a data room is waiting.