The technology competence duty and what it means for vendors

A lawyer's ethical duties used to stop at their own conduct. Comment 18 to ABA Model Rule 1.1 extended that duty to include understanding the tools the lawyer relies on, and as of 2026, forty states have adopted some version of the standard [1]. For a legal technology vendor, that duty flows directly into what your product has to be able to demonstrate.

What the duty actually says

Model Rule 1.1 requires a lawyer to provide competent representation, and Comment 18 clarifies that competence includes staying abreast of the benefits and risks associated with relevant technology. That single sentence has grown into a real vetting practice: a lawyer adopting a new piece of software is now expected to understand, at least at a basic level, what that software does with client information and what could go wrong.

The practical consequence for a firm is that adopting a new tool without asking any questions about it is itself a competence problem, separate from whatever the tool's actual security posture turns out to be. A firm that later has an incident with a poorly vetted vendor cannot simply point at the vendor; the firm's own failure to ask questions before adopting the tool is part of what a bar disciplinary review or a malpractice claim would look at.

What this means for a vendor

This duty puts your product in an unusual position compared to most B2B software. Your buyer is evaluating whether your product solves their problem and, at the same time, building a record that they exercised competence in choosing you. If your product cannot support that record, you have made your buyer's compliance harder even if your actual security is fine.

Concretely, a firm evaluating legal software is increasingly likely to ask: where is client data stored, and in which jurisdictions. Who at the vendor can access client data, under what circumstances, and is that access logged. What happens to data if the firm stops using the product. Is data encrypted at rest and in transit, and what happens to backups. Does the product use AI features that process client data, and if so, is that data used to train models or retained across sessions in a way that could expose one client's information to another matter. Each of those questions traces back to a real obligation somewhere else in this guide, and a product that cannot answer them clearly and specifically is asking its buyer to accept a competence risk on faith.

Documentation the firm can actually use

The response to this duty is documentation specific enough that a firm's own risk or compliance function can put it in a file and point to it later if asked. That typically means a plain description of the data flow: what is collected, where it is stored, who can access it and under what conditions, how long it is retained, and what happens on account termination. It also means being direct about any AI features, since those are the newest and least well-understood part of the technology-competence question, covered separately in AI drafting features and confidentiality risk.

This documentation is worth treating as a product requirement rather than a sales afterthought, because the alternative is worse than losing a deal. A vague or evasive answer to a basic data-handling question costs the sale and signals to a careful buyer that the underlying practice may not exist at all, which is often a fair inference.

The duty does not end at the sale

Comment 18's requirement that a lawyer stay abreast of the risks and benefits of relevant technology is ongoing, not a one-time check performed before a contract is signed. A firm that vetted a product carefully three years ago and never revisited that review as the product added features, most notably an AI feature that did not exist at the time of the original evaluation, has a gap in the same ongoing duty, and that gap is partly the vendor's to help close.

The practical implication is that vendor documentation needs a visible version history and a clear notice process when something material changes: a new subprocessor added, a new AI feature introduced, a change in where data is stored or how long it is retained. A firm cannot reasonably re-vet a vendor on a schedule if the vendor gives no signal that anything changed. Building a simple, dated changelog into vendor-facing documentation, rather than silently updating a page and letting the old version disappear, turns a one-time due diligence exercise into something a firm can actually maintain over the life of the relationship.

The connection to confidentiality controls

The technology competence duty and the confidentiality duty covered in ABA Rule 1.6 confidentiality controls for legal software reinforce each other rather than standing apart. Rule 1.6(c) is about whether the product's actual controls are adequate. The technology competence duty is about whether the lawyer understood and evaluated those controls before relying on them. A vendor that has strong Rule 1.6 controls but cannot explain them clearly has only solved half the problem their buyer actually faces, because the firm still cannot demonstrate the informed choice the competence duty requires.

What good vendor documentation looks like

Good vendor documentation gives a firm's compliance function specifics they can act on: a plain account of the data flow, written in language a non-engineer can follow, that the firm can point to later if asked. A security certification badge with no supporting detail, or a lengthy legal document written to protect the vendor rather than inform the buyer, leaves that same compliance function with nothing concrete to record. If your product's documentation reads like reassurance rather than description, rewrite it around the specific questions in the previous section until it does.

Whether a specific level of vendor disclosure satisfies a specific state's interpretation of the technology competence duty is, like everything else in this guide, a question that depends on the jurisdiction and the facts, and it is worth having counsel review your vendor-facing documentation the same way you would review a customer contract. Get in touch if you want help building that documentation into the product itself rather than as a separate document that goes stale.