ABA Rule 1.6 confidentiality controls for legal software

Lawyers have owed clients a duty of confidentiality for as long as the profession has existed. What changed is where client information now lives: emails, document management systems, e-signature platforms, case management software, and increasingly AI drafting tools. ABA Model Rule 1.6(c) was written to keep the duty current with that shift, and it reaches directly into the software a lawyer chooses to use.

What the rule actually requires

Rule 1.6(c) requires a lawyer to make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client [1]. That duty extends to digital data specifically: emails, electronic documents, and the metadata attached to them.

The phrase doing the real work is "reasonable efforts," because it does not mean perfect security. It means a standard of care a lawyer has to be able to demonstrate they met, which in practice means they have to be able to describe what protections were in place and why those protections were reasonable given the sensitivity of the information. A lawyer who has no idea what access controls their case management software actually enforces cannot make that showing, no matter how good the software's controls happen to be, because "reasonable efforts" implies some level of informed choice.

That is the mechanism by which your product's design becomes part of a licensed professional's ethical obligation. If your access controls are weak, the lawyer using your product cannot make reasonable efforts against unauthorized access, because the tool they are relying on does not support it. If your controls are strong but undocumented, the lawyer still cannot describe what protections were in place if asked, because nobody told them.

Where internal access is the actual risk

Most conversations about confidentiality default to outside attackers, and that is a real risk, but it is not the one Rule 1.6(c) is most often silently exposed to in legal software specifically. The more common gap is internal: an employee at a firm who can see another attorney's client files because the permission model does not separate them, or a support engineer at the software vendor who has standing access to client documents for troubleshooting purposes that were never audited or time-limited.

Both of those are unauthorized access under the rule's own language, because the rule does not carve out an exception for access by people who happen to work at the firm or the vendor rather than outside it. A product's permission model needs to separate one attorney's clients from another's by default, not as an optional configuration a firm has to know to turn on, and any standing access a vendor's own staff hold needs to be logged, time-limited, and itself covered by an audit trail, the same requirement covered in more general form on our audit trails page for financial services, which applies with equal force here.

Metadata is explicitly covered, and usually mishandled

The rule's explicit mention of metadata is not incidental. A document sent to opposing counsel or filed with a court can carry metadata revealing prior edits, comments, or draft language never meant to leave the firm, and stripping that metadata before a document leaves the system is a control most legal software either does not offer or leaves off by default.

The practical requirement is that any document export or sharing feature strips or flags metadata before the document leaves your product's boundary, rather than leaving it for the user to remember to handle in whatever word processor they open the file in afterward. A feature that exports a document with full revision history intact, presented as if it is a clean copy, creates exactly the disclosure risk Rule 1.6(c) exists to prevent, and it is a defect in the product rather than a mistake by the lawyer using it.

What a check for this looks like

Because the rule is written as a standard, "reasonable efforts," rather than a specific technical requirement, translating it into a check means deciding what reasonable looks like for your product's actual risk profile and then testing that the system holds to it consistently.

A useful starting set: assert that one firm's client records are never returned in a query scoped to another firm's account, tested directly rather than assumed from the data model. Assert that any vendor-side administrative access to client data produces its own audit entry, separate from ordinary user activity, and expires rather than persisting indefinitely. Assert that a document export strips metadata by default, and that a user has to take a deliberate additional action to retain it. Assert that encryption covers the data at rest and in transit, including in backups and any analytics or search index that has a copy of client content, reaching well past the primary database.

Each of those is testable, and each one traces directly back to a specific piece of the rule's language, which is the same method covered in more depth on evals as legal compliance evidence.

The multi-tenant boundary is the hardest part to hold

Most legal software serves more than one firm, and often more than one attorney within a single firm handling entirely unrelated clients. That structure means the confidentiality boundary Rule 1.6(c) requires is many separate walls, one for each client relationship, that all have to hold independently and continuously as the product grows.

The place this tends to fail first is a shared feature added for convenience: a firm-wide search that indexes every matter for speed, a reporting dashboard that aggregates activity across clients for a partner's overview, a notification system that surfaces recent activity without checking who is allowed to see it. Each of these is a reasonable feature to want, and each one is a place where the boundary between one client's confidential information and another's can quietly erode if the feature was built by querying broadly and filtering at the display layer, rather than by scoping the underlying query itself. A filter applied after the data is already retrieved is a weaker guarantee than a query that never retrieves the wrong data in the first place, because the filter can be forgotten in the next feature that reuses the same underlying function.

What this does not cover

Rule 1.6(c) covers confidentiality, not the separate question of whether a lawyer is competent to select and use the technology in the first place. That second duty, the duty of technology competence, is a distinct obligation and is covered on technology competence duty and what it means for vendors. Whether a specific product's controls satisfy a specific bar's interpretation of "reasonable efforts" is also a question for counsel familiar with that jurisdiction's ethics opinions, not something a generic build guide can settle. Get in touch if you want help building or auditing these controls in an existing product.