How Law Firms Can Test IT Security Before Rolling Out Another AI Tool
Fusion Legal & Tax · October 16, 2026Thought Leadership6 min read
Rolling out an AI tool confidently requires more than reviewing the application itself. Your firm also needs to understand the infrastructure through which lawyers reach it—including identity systems, email, endpoints, document repositories, backups, integrations, and the IT help desk.
That connective tissue is commonly managed by a managed service provider, or MSP. In practical terms, the MSP may be part of the firm’s AI control environment even when it never sells an AI product.
The protective opportunity is straightforward: treat managed IT as a governed extension of the firm, not merely a support subscription. A strong MSP relationship should help lawyers work confidently within clear boundaries, while preserving evidence that those boundaries operate as intended.
Know what your IT provider can see, change, and recover
An MSP questionnaire should begin with what the provider can see, change, approve, recover, and export. Firms should map at least five forms of authority:
- Identity authority: Can MSP personnel reset passwords, enroll authentication factors, create accounts, or change group membership?
- Endpoint authority: Can they remotely access laptops, deploy software, disable security tools, or copy files?
- Repository authority: Can they administer the document-management, case-management, email, or backup environment?
- Integration authority: Can they approve connections between an AI product and Microsoft 365, a DMS, a CRM, or another system of record?
- Recovery authority: Can they restore deleted messages, matter files, or historical backups—and who can authorize that work?
This inventory is more useful than asking whether the provider offers “law firm security.” It identifies the paths by which an ordinary support action could affect confidential information.
Make security promises clear and testable
The current market vocabulary includes confidentiality controls, encryption, data-loss prevention, ethical walls, retention, rapid response, and continuous monitoring. Those terms are meaningful only when the firm can connect each one to scope, ownership, evidence, and exceptions.
For example, SADOS describes its law-firm IT service as including matter-specific access controls, email encryption, DMS support, daily backups, documented ethical walls, and tested recovery procedures. It also states: “We respond within 4 hours during business hours and treat court deadline issues as a priority.” That wording still leaves useful diligence questions: what “priority” means in response and resolution terms, how after-hours filing emergencies are handled under this service description, and how account-takeover reports are triaged.
For each promised control, firms should request a focused evidence package:
| Promise | What the firm should define | Evidence to request |
|---|---|---|
| Role-based access | Covered systems, matter-level rules, approvers, exceptions | Access matrix and sample access-review record |
| Ethical walls | Trigger, implementation owner, affected applications, validation method | Configuration record and test result |
| Email encryption | Automatic triggers, user overrides, external-recipient workflow | Policy export and delivery test |
| Backup and retention | Systems covered, frequency, retention period, deletion handling | Backup inventory and recent restore-test record |
| Rapid response | Severity definitions, business-hours limits, escalation path | Service-level schedule and escalation roster |
| Remote support | Identity verification, permitted tools, session recording, file-transfer rules | Support procedure and representative audit log |
The goal is not paperwork for its own sake. It is to ensure that lawyers, internal operations personnel, the MSP, and any AI vendor share the same definition of “protected.”
Make legitimate IT support easy to recognize
Remote support deserves special scrutiny because it combines technical privilege with human trust. A technician may be able to reset credentials, enter an endpoint, change permissions, or guide a user through a sensitive action. That makes the help desk an identity-verification function—not simply a ticket queue.
As reported by Law360 on October 2, 2026, that year had seen several high-profile cyberattacks on law firms, reflecting the increased role AI was playing in security incidents and the growing sophistication of threat actors targeting the legal industry. That trend makes help-desk verification a practical part of AI-era security.
A firm can respond protectively by making legitimate support behavior easier to recognize. Useful controls include:
- requiring staff to initiate remote sessions through a known portal or published number;
- prohibiting technicians from requesting passwords or authentication codes;
- requiring a second approval for multifactor-authentication resets and privileged-account changes;
- displaying technician identity and ticket number before remote access begins;
- restricting file transfer during support sessions unless separately approved;
- logging remote access, administrative changes, and data exports; and
- creating a familiar internal channel for verifying an unusual request without relying on contact details supplied in the request itself.
A tabletop exercise should test these procedures. Have an authorized tester pose as the MSP and request an urgent authentication reset, remote-control session, or transfer of a client document. Measure whether personnel verify the request, whether the MSP detects the impersonation, and whether escalation records are preserved.
Connect the MSP review with the AI-vendor review
AI due diligence and MSP diligence should not run on separate tracks. The AI vendor may govern the model and application, while the MSP governs the identity, endpoint, email, repository, and network conditions surrounding it.
Thomson Reuters’ AI-vendor diligence guidance recommends obtaining specifics about where AI-generated data is stored, who can access it, whether communications or transaction data are used for training, who retains rights to the information, how data is deleted, and whether information is shared with third parties. It identifies vague security answers, unclear deletion policies, and reluctance to discuss third-party sharing as warning signs.
Those questions should be carried into an integration review:
- Does the AI application inherit permissions from the source repository, or can it expose material more broadly?
- Can an administrator authorize a firmwide connector without a second approver?
- Which party logs prompts, retrieved documents, generated outputs, permission changes, and exports?
- Can the MSP view AI-session content while troubleshooting?
- Does disabling a user in the firm’s identity system promptly terminate AI access?
- When a matter closes or a user leaves, which party removes cached, indexed, or synchronized copies?
- If the integration is disconnected, what data remains with each provider?
No single vendor should answer only its own narrow portion of these questions. The firm needs an end-to-end data-flow diagram and a clear ownership matrix covering the handoffs.
Keep confidentiality, privilege, and security distinct
Technology proposals sometimes use “privilege protected” as shorthand for encryption and access controls. Firms should resist that compression.
Security controls can limit unauthorized access, preserve logs, and support disciplined handling of sensitive material. They do not independently determine whether a communication is legally privileged, whether privilege has been waived, or whether a particular person should receive a document. Those remain legal and factual questions requiring lawyer oversight.
Procurement language should therefore describe what the technology actually does: encrypts specified traffic, limits access by role or matter, records administrative activity, prevents defined transfers, or restores covered data. Precision protects both the firm and the provider from relying on a slogan that reaches beyond the underlying control.
A practical pre-purchase gate
Before approving another AI tool, law-firm leadership should ask the MSP, AI vendor, and internal owner to complete one shared control record:
- Data involved: What client, firm, personnel, or operational information will enter the workflow?
- Systems connected: Which identity, email, DMS, case-management, billing, or storage environments are implicated?
- People with access: Which firm personnel, MSP technicians, vendor personnel, and subprocessors can reach the data or administer the system?
- Permitted uses: What is the approved task, and what uses remain outside scope?
- Retention and deletion: Where are prompts, files, indexes, logs, and outputs retained, and how is deletion verified?
- Support boundaries: What can technicians access, and what additional approval is required for sensitive actions?
- Incident ownership: Who contains, investigates, preserves evidence, communicates, and decides whether the integration stays active?
- Exit procedure: How are access, connectors, tokens, synchronized data, and provider-held copies removed?
The strategic point is larger than cybersecurity. Law firms cannot scale AI responsibly if their application governance stops where managed IT begins. The firms best positioned to adopt AI with confidence will be the ones that make every technical handoff visible, assign an owner to every privileged action, and test whether the promised controls work before a consequential matter depends on them.
This article provides general educational information for legal-industry professionals and is not legal advice for any particular firm, system, or incident.