Smotrów Design is a global design and technology company. Our commitment
- office@smotrow.com
- Smotrow Signature
- Smotrów Related
- Local time: 9:57 AM
Smotrów Design is a global design and technology company. Our commitment
This article explains how we design for confidentiality - and how any team building legal software should approach it.
A software engineer building a SaaS product for marketing teams thinks about security in terms of encryption, authentication, and access control. Important - but relatively straightforward. The data is commercially sensitive, not professionally sacred.
A software engineer building legal technology faces a fundamentally different challenge. The data is protected by attorney-client privilege - a legal doctrine with constitutional standing in most jurisdictions. Breaching it is not a security incident. It is a professional ethics violation that can result in disqualification from a case, disciplinary sanctions, malpractice liability, and destruction of the attorney-client relationship.
This is why security in legal software cannot be treated as a technical layer. It must be treated as an architectural principle that informs every decision from the data model to the notification design.
At Smotrów Design, we have spent more than a decade building legal software under these constraints. Jusnote, the practice management platform we designed and continue to develop, enforces confidentiality at every layer - from database schema to mobile push notifications. The Legal Positions Database we built for the Supreme Court of Ukraine handles judicial data that carries its own institutional confidentiality requirements. Two of our founding partners are former practicing lawyers who understand privilege not as a technical requirement but as a professional obligation they once lived under daily.
This article explains how we design for confidentiality - and how any team building legal software should approach it.
The first architectural decision is understanding what confidentiality means in legal practice - and how it differs from what engineers typically call "security."
Security protects data from unauthorized external access. Confidentiality protects data from unauthorized internal access - including access by other authorized users of the same system. A law firm's practice management platform must prevent Attorney A from seeing Attorney B's matters when the two represent adverse parties. Both attorneys are authenticated, authorized users of the system. Both have valid credentials and appropriate roles. The system must still prevent access - not because of a security policy, but because of an ethical obligation.
This means standard role-based access control (RBAC) is necessary but insufficient. Legal software requires matter-level access control, ethical wall enforcement, temporal access management, and context-aware information display - all enforced at the data layer, not just at the interface layer.
Standard role-based access control is necessary but insufficient for legal software. Confidentiality requires matter-level enforcement at the data layer.
Confidentiality must be enforced not only in data storage but in every interaction with the interface. This is where most legal software fails - the data is properly secured in the database, but the interface leaks information in ways the engineering team did not anticipate. As we covered in our article on designing interfaces that lawyers adopt, interface decisions in legal software carry weight that interface decisions in other industries do not.
Push notifications are the most common source of privilege leaks in legal software. A notification that reads "New document uploaded to Anderson v. Martinez, Case No. 2026-CV-1847" displays privileged information on the phone's lock screen - visible to anyone who glances at the device on a conference table, in a courtroom, or in a shared office.
The design rule: notifications must never display client names, matter descriptions, case numbers, or any information that identifies a specific representation. A notification should read "New document uploaded" or "You have a new task" - with matter details visible only after the user authenticates and opens the application.
This applies equally to email notifications, browser notifications, and smartwatch alerts. Every notification channel is a potential privilege leak.
When a lawyer searches for a term - a client name, a legal concept, a document title - the results must be filtered by the lawyer's access permissions before rendering. Not after rendering. Not with a "you don't have access" message that confirms the existence of a matter the lawyer should not know about.
The distinction matters. If Attorney A searches for "Anderson" and the system returns a result saying "Anderson v. Martinez - Access Denied," Attorney A now knows that the firm represents someone in a matter involving Anderson. This knowledge itself may constitute a conflict. The search must return no result at all for matters outside the attorney's access scope.
During video calls, lawyers frequently share their screen. During in-person meetings, colleagues and clients may see a lawyer's monitor. The interface must assume that screen content may be visible to unauthorized viewers at any time.
This affects sidebar design (matter lists, recent documents, and notification panels should not display information from unrelated matters), dashboard content (financial data, client names, and matter statuses should be filterable by the lawyer's current context), and idle-state behavior (what the screen shows when the lawyer is not actively interacting - a neutral state that does not expose the firm's client roster).
Mobile applications introduce additional privacy challenges. Auto-complete in search fields may suggest matter names to someone who borrows the phone. App preview screens (visible in the task switcher) may display matter data. Copy-paste functionality may allow privileged text to be pasted into non-secure applications.
Each of these scenarios must be addressed in the mobile application's design - not as edge cases, but as standard operating conditions.
An ethical wall (also called a Chinese wall or information barrier) is a mandatory separation between lawyers within the same firm who are working on matters that create a conflict of interest. Ethical walls are not optional - they are required by professional conduct rules in most jurisdictions.
When an ethical wall is established between Attorney A and Attorney B regarding a specific matter, the system must prevent Attorney A from accessing any data related to Attorney B's matter (documents, time entries, communications, client information), prevent Attorney A from seeing the matter in search results, matter lists, dashboards, reports, or any other interface element, prevent the system from routing notifications about the walled matter to Attorney A, log any attempt by Attorney A to access the walled matter (even if blocked), and maintain the wall until it is formally lifted by an authorized administrator.
Ethical walls must be enforced at the database query level, not at the interface level. Every database query that returns matter data must include a filter that excludes walled matters for the requesting user. This means the wall is enforced regardless of how the data is accessed - through the web interface, the mobile app, an API call, or a reporting tool.
A common implementation failure: the wall is enforced in the web interface but not in the reporting module. A partner runs a firm-wide revenue report and sees billing data from a walled matter. This is a privilege breach with potential professional consequences.
Legal access control operates on multiple dimensions simultaneously.
Partners, associates, paralegals, billing administrators, and firm administrators each have different default permissions. A paralegal can view and edit documents but cannot approve invoices. A billing administrator can process invoices but cannot access matter strategy documents.
Each matter has an explicit access list: which users can view it, which can edit it, which can see its financial data. This list overrides role-based defaults - a partner who is not on a matter's access list cannot see it, even though their role would normally permit access to all matters.
In larger firms, access may be scoped by practice group. A corporate attorney does not need access to litigation matters and vice versa. Practice group boundaries reduce the scope of potential conflicts and limit the blast radius of any access control failure.
Access must be revocable and time-bounded. When an attorney leaves the firm, their access must be terminated immediately - but the audit trail of their previous access must be preserved. When a temporary team member is brought onto a matter, their access should have an explicit expiration date.
Some access controls operate at the client level rather than the matter level. If an attorney has a conflict with a client, they must be blocked from all matters involving that client - including future matters that have not yet been opened.
Trust accounting is not a billing feature. It is a data architecture constraint that affects the entire financial subsystem of a legal practice management platform. We explored the broader architectural implications in our guide to building a legal practice management system from scratch.
In most jurisdictions, law firms must maintain strict separation between operating funds (the firm's own money) and client trust funds (money held on behalf of clients - retainers, settlement funds, escrow deposits). Commingling these funds - even accidentally, even temporarily - is a disciplinary violation that can result in suspension or disbarment.
This means the financial data model must enforce separation at the database level. Operating and trust transactions cannot share a ledger. A database query that calculates the firm's revenue must be structurally incapable of including trust funds in the total. This is not a reporting filter - it is a schema constraint.
Individual client trust balances - each client's trust funds tracked as a separate ledger within the trust account. Earned fee transfers - when the firm bills a client and the client has funds in trust, the system must record the transfer from trust to operating as a discrete transaction with a full audit trail. Interest allocation - in jurisdictions that require interest on client trust funds, the system must calculate and allocate interest to individual client balances. Three-way reconciliation - the ability to reconcile the bank balance, the book balance, and the sum of individual client balances at any point in time. Overdraft prevention - the system must prevent any transaction that would cause an individual client's trust balance to go negative.
Trust accounting is not a billing feature. It is a schema constraint that must be enforced at the database level.
Every action in a legal software system must be logged. Not for debugging - for professional accountability. The audit trail serves multiple purposes: internal governance, bar association compliance reviews, malpractice defense, and regulatory investigations.
Every data access: who viewed which matter, which document, which financial record - and when, from which device, and from which IP address. Every data modification: who changed what, when, and what the previous value was. Every access control change: who granted or revoked access to whom, for which matter, and when. Every authentication event: logins, failed login attempts, password changes, session expirations. Every export: who exported data from the system, what data, in what format, and when.
Audit logs must be immutable - no user, including system administrators, should be able to modify or delete audit records. This is typically implemented as an append-only log stored in a separate database or service, with write-only access from the application and read-only access for authorized reviewers.
The audit trail must be searchable. A firm administrator responding to a bar association inquiry about who accessed a specific matter during a specific period must be able to retrieve that information quickly and definitively.
A legal software product serving firms across multiple jurisdictions must comply with different data protection regimes simultaneously. Multi-jurisdictional compliance is an architectural requirement - not a configuration option that can be added after the core product is built.
Some jurisdictions require that personal data be stored within their borders. A firm in the EU using a practice management platform hosted on US servers may violate GDPR requirements. The platform must support data residency controls - the ability to specify where data for specific clients or matters is physically stored.
Different jurisdictions have different rules about consent for data processing. The platform must support configurable consent workflows that can be adapted to EU (GDPR), UK (UK GDPR), US (state-specific privacy laws), and other regulatory frameworks without code changes.
Individuals have the right to access, correct, and in some cases delete their personal data. The platform must support these rights while preserving the firm's professional obligations - which may require retaining certain records even after the data subject requests deletion. The system must be able to distinguish between data that can be deleted and data that must be retained for professional compliance.
Different jurisdictions have different requirements for notifying individuals and authorities when a data breach occurs. The platform's monitoring and alerting infrastructure must support configurable breach detection and notification workflows.
Beyond the application-level confidentiality measures, the underlying infrastructure must meet enterprise security standards.
Data encrypted at rest (AES-256 or equivalent) and in transit (TLS 1.3). Database-level encryption for sensitive fields (client names, matter descriptions, financial data) in addition to disk-level encryption.
Multi-factor authentication as default, not optional. Single sign-on (SSO) integration for enterprise clients. Session management with configurable timeout periods and forced re-authentication for sensitive operations.
Web application firewall, DDoS protection, intrusion detection, and continuous vulnerability scanning. Regular penetration testing by independent security firms.
Automated backups with geographic redundancy. Recovery time objectives (RTO) and recovery point objectives (RPO) documented and tested. Backup data encrypted with the same standards as production data.
SOC 2 Type II as a baseline. ISO 27001 for organizations with international clients. Industry-specific certifications as required by target market segments.
The consequences of a confidentiality failure in legal software are not abstract.
A privilege breach can disqualify a firm from representing a client in a matter worth millions. An ethical wall failure can create malpractice liability. A trust accounting error can trigger bar association sanctions including suspension. A data protection violation can result in regulatory fines under GDPR (up to 4% of global revenue) or state-specific privacy laws. And the reputational damage - a law firm known for a data breach - can cost more than any fine.
These are not hypothetical risks. They are the reason that confidentiality in legal software must be treated as architecture, not as a feature.
When AI is added to the equation, the stakes multiply. As we discussed in our article on AI in legal software, AI components must operate within these confidentiality constraints - not as independent systems with their own data access patterns.
Security in legal software is not about preventing hackers from accessing the database. It is about ensuring that every interaction with the system - every search, every notification, every report, every screen - respects the professional obligations that define legal practice.
This requires confidentiality as a first-order architectural constraint, not a feature added after the core product is built. It requires ethical walls enforced at the database layer, not at the interface layer. It requires trust accounting as a schema constraint, not a reporting filter. It requires audit trails that are immutable, comprehensive, and searchable. And it requires multi-jurisdiction compliance designed into the data model, not configured after deployment.
These are the principles that guide every legal software product we build at Smotrów Design. They are the reason Jusnote earns the trust of law firms that handle their most sensitive client matters through our platform.
This article is part of our series on building legal software that lawyers will actually use. For UX-specific guidance, see our article on designing interfaces that lawyers adopt. For how to build the practice management platform these security principles protect, see our guide on building a legal practice management system from scratch. For how AI must operate within these confidentiality constraints, see our article on AI in legal software.
