Episode 25 · Module 6 · Authorization & Access Control

Ethical Walls and Matter-Scoped Access

19 May 2026 · 9:02 · Security for Legal SaaS

9:02 9:02

Two partners at the same firm. One advises the acquiring company. The other advises the target. Same firm, opposite sides of the same transaction. If either partner sees the other's client communications — deal strategy, negotiation positions, privileged legal advice — it's not just a security incident. It's a professional ethics violation that can result in disqualification, sanctions, and malpractice liability.

Today’s Lesson

Security for Legal SaaS — Episode 25: Ethical Walls and Matter-Scoped Access

The Conflict Problem

This is the problem ethical walls solve. And for legal SaaS platforms, it's not optional — it's a regulatory requirement that your software must enforce.

Professional Rules: ABA Model Rules 1.7, 1.9, and 1.10

The obligation to prevent conflicts of interest is codified in ABA Model Rule 1.7 (concurrent conflicts) and Rule 1.9 (duties to former clients). When a conflict exists, Rule 1.10 addresses imputation — the principle that one lawyer's conflict is imputed to every lawyer in the same firm.¹

Rule 1.10(a)(2) provides the critical exception: if the conflicted lawyer is timely screened from any participation in the matter and receives no part of the fee, the imputation can be overcome. The screen must include:²

Written notice to affected parties
A description of screening procedures employed
Affirmation of compliance
An agreement to respond to inquiries about the screen

Key insight for software builders: The rules don't just require that the wall exists — they require proof that it works. Your platform must produce evidence: audit logs showing who accessed what, when the wall was erected, and that screened individuals never accessed restricted material.¹

Ethical Walls vs. Multi-Tenancy

This is a crucial distinction that will matter in Episode 27:

Concept	Scope	Example
Ethical wall	Intra-tenant — within a single firm	Partner A cannot see Partner B's matter files
Multi-tenant isolation	Inter-tenant — between different firms	Firm A cannot see Firm B's data at all

Ethical walls are harder to implement than multi-tenant isolation because you're creating information barriers within a shared environment. Both users have legitimate accounts in the same firm's instance. Both have roles that would normally grant them access to the same categories of resources. The wall is an exception — a targeted restriction that overrides normal permissions.³

Matter-Scoped Access: The Foundation

The foundation of ethical walls in legal SaaS is matter-scoped access — ensuring that every data access decision includes not just "what role does this user have?" but "is this user assigned to this matter?"

In Episode 23, we covered RBAC roles. In Episode 24, we covered ABAC attributes. Matter scoping combines both:

Access granted IF:
  1. User has the required ROLE permission (e.g., Associate can read documents)
  AND
  2. User is ASSIGNED to this specific matter
  AND
  3. No ethical wall BLOCKS this user from this matter

The matter assignment is the default access scope. The ethical wall is an additional restriction layer that can override normal access — even for users who would otherwise qualify.

Technical Implementation

Static Walls vs. Dynamic Walls

Static walls are configured manually by a firm administrator: "Attorney X must not access Matter Y." These are simple to implement — a deny-list checked on every access request — but they require someone to know the conflict exists and remember to configure the wall.

Dynamic walls are triggered automatically by conflict checking systems. When a new matter is opened, the system compares the parties involved against existing matters and identifies potential conflicts. If a conflict is found, the wall is erected automatically — no manual step required.⁴

For legal SaaS platforms, dynamic walls are the standard. A new matter for a client creates a conflict with any existing adverse representation. The system should:

Run a conflict check when the matter is created
Identify all lawyers with conflicting matter assignments
Automatically erect walls barring those lawyers from the new matter
Notify the affected parties (per Rule 1.10's notice requirement)
Log the wall creation with a timestamp and reason

Database-Level Enforcement

Ethical walls must be enforced at the database query level, not just the application layer. Every query that retrieves matter data must include a wall check:

sql

SELECT d.* FROM documents d
JOIN matter_assignments ma ON d.matter_id = ma.matter_id
WHERE ma.user_id = :current_user
  AND d.matter_id NOT IN (
    SELECT matter_id FROM ethical_walls
    WHERE blocked_user_id = :current_user
    AND active = true
  )

If your wall enforcement only exists in the application layer and a developer writes a new database query that skips the check, the wall is breached. Defence in depth — a concept from Episode 4 — means implementing wall enforcement at multiple layers:⁵

Layer	Enforcement
Database	Row-level security policies or view-based filtering that exclude walled matters
API middleware	Permission check that rejects requests for walled matters before reaching business logic
UI	Walled matters are invisible in search results, matter lists, and navigation
Search index	Walled matter documents are excluded from full-text search results

Cross-Matter Search: The Hard Problem

Law firms need firm-wide search — the ability to search across all matters for precedent, prior work product, or knowledge management. But firm-wide search creates a conflict with ethical walls: how do you let a lawyer search across hundreds of matters without returning results from a matter they're walled off from?

The solution is pre-filtered search indexing:

The search index (Elasticsearch, Solr, or similar) is tagged with matter IDs and wall metadata
At search time, the query includes a filter that excludes all matters where the current user has an active wall
Results from walled matters are never returned — not even snippets or metadata
The user has no indication that results were suppressed (to avoid revealing the existence of the conflict)

Critical detail: Even revealing that a wall exists can be a confidentiality breach. If a lawyer searches for "Acme Corp acquisition" and sees a message saying "2 results hidden due to an ethical wall," they now know the firm has an adverse matter involving Acme Corp. The correct behaviour is silent suppression — walled results simply don't appear.⁶

Audit Requirements

Proving wall integrity is as important as implementing it. Regulators, clients, and opposing counsel may demand evidence that the wall was effective. Your audit log must capture:⁷

Event	Required Data
Wall creation	Timestamp, triggering conflict, affected matter(s), affected user(s), creator
Wall modification	What changed, who authorised it, why
Access attempts	Every request where a wall was evaluated, including denials
Wall removal	When the wall was lifted, who authorised it, certification of no breach
Periodic attestation	Quarterly or annual confirmation that walls remain in place

These logs must be immutable — once written, they cannot be edited or deleted, even by firm administrators. This is a case where your audit infrastructure (which we'll cover in later episodes) directly supports a professional conduct obligation.

The SRA Perspective

The UK Solicitors Regulation Authority (SRA) imposes similar requirements under its Code of Conduct paragraphs 6.2-6.5.⁸ The SRA has been explicit that firms relying on information barriers must demonstrate that the barriers are effective in practice — not just documented in policy. Software-enforced walls with audit trails are increasingly the expected standard, not just a best practice.

Real-World Failures

Information barrier failures have led to firm disqualification in multiple jurisdictions:

In Petter v EMC Europe Ltd ²⁰¹⁵ EWCA Civ 828, the English Court of Appeal examined whether an information barrier at a law firm was sufficient to prevent imputation of knowledge between lawyers working on opposite sides of a dispute.⁹
US courts have disqualified firms where ethical screens were found to be "paper screens" — documented procedures that were not actually enforced in practice. Software-enforced walls with access logs provide stronger evidence than policy documents alone.

What's Next

Episode 26 covers Zero Trust Architecture — the security model that assumes no user, device, or network location should be trusted by default, and how it extends the defence-in-depth principles from Episode 4 into continuous verification.

Sources & Further Reading

Sources & references

ABA, Model Rule 1.10: Imputation of Conflicts of Interest — screening requirements and notice obligations.
ABA, Model Rule 1.7: Conflict of Interest — Current Clients — concurrent conflict rules.
GreenPoint Legal, Building Ethical Walls Using Modern Technology — technology implementation of ethical walls.
Tessaract, Chinese Walls: What Are They? — practical overview of information barriers in legal practice.
OWASP, Authorization Cheat Sheet — defence in depth for access control.
Wikipedia, Chinese Wall — history and application across industries.
US Legal Forms, Ethical Wall: Legal Definition and Importance — audit and compliance requirements.
SRA, Code of Conduct for Solicitors — paragraphs 6.2-6.5 on conflicts and information barriers.
Thomson Reuters Practical Law, Chinese Walls: Maintaining Client Confidentiality — UK legal framework for information barriers.
Downey Law Group, Elements of an Effective Ethics Screen — screening procedure design.
ABI, The Unsavory Origins of the Term "Chinese Wall" — terminology history and modern alternatives.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 25 — ethical walls and matter-scoped access. Alice, this one feels very specific to legal software. What's the problem we're solving?

Alice: Picture this. Two partners at the same law firm. Partner A advises the company trying to make an acquisition. Partner B advises the company being acquired. Same firm. Opposite sides of the same deal. If Partner A sees Partner B's client communications — the target's negotiation strategy, their bottom line, their privileged legal advice — that's not just a data breach. It's a professional ethics violation. The firm can be disqualified from representing either client. There can be sanctions, malpractice claims, and regulatory action. Your software has to prevent that from happening.

Dan: Mm. So this is a regulatory requirement, not just a nice-to-have security feature?

Alice: Absolutely. The ABA Model Rules — Rule 1.7 for current client conflicts, Rule 1.9 for former clients, and Rule 1.10 for imputation — require that when a conflict exists, the conflicted lawyer is "timely screened" from any participation in the matter. And the screening has to include written notice to affected parties, a description of the procedures, and ongoing compliance. The rules don't just say "put up a wall." They say "put up a wall and prove it works."

Dan: Right. And the proof part is where the software comes in?

Alice: Exactly. An ethical wall in software means that a screened lawyer cannot see the conflicting matter's documents, cannot search for them, cannot access them through any path in the application. And every time the system evaluates that wall — every time it blocks an access attempt or even runs the check — it logs it. Those logs are the proof. When a regulator or opposing counsel asks "was this wall effective?", you can show timestamped records of every access decision.

Dan: Hmm. How is this different from the multi-tenant isolation we'll talk about later? That's about keeping different firms' data separate, right?

Alice: Good distinction. Multi-tenant isolation — which we'll cover in Episode 27 — is about keeping Firm A's data completely separate from Firm B's data. That's inter-tenant isolation. Ethical walls are intra-tenant — within a single firm. And they're actually harder to implement, because both users have legitimate accounts in the same firm. Both have roles that would normally grant them access. The wall is an exception — a targeted restriction that overrides their normal permissions for specific matters.

Dan: Mm. So you're carving out exceptions from the RBAC system we talked about in Episode 23?

Alice: Exactly. The access decision has three layers now. First, does the user's role grant them permission for this type of action? That's RBAC. Second, is the user assigned to this specific matter? That's matter scoping. Third, is there an active ethical wall that blocks this user from this matter? That's the wall check. All three must pass, and the wall check is a hard deny — it overrides the first two even if they would normally allow access.

Dan: Yeah. Now, you said these walls can be static or dynamic. What's the difference?

Alice: A static wall is set up manually by a firm administrator. Someone identifies a conflict and configures the wall: "Attorney X cannot access Matter Y." It works, but it depends on someone knowing about the conflict and remembering to configure the wall. A dynamic wall is triggered automatically by the conflict checking system. When a new matter is opened, the system compares the parties involved against all existing matters. If it finds a potential conflict — same party, adverse representation — it erects the wall automatically. No manual step.

Dan: Mm-hmm. Dynamic sounds much safer.

Alice: It is. And it's the expected standard in modern legal SaaS. The system should run the conflict check on matter creation, identify all lawyers with conflicting assignments, automatically block their access to the new matter, notify the affected parties — which the ABA rules require — and log everything with timestamps and reasons.

Dan: Right. Where should the wall actually be enforced technically? In the application code?

Alice: <sigh> Not just the application code. This is defence in depth — we talked about that concept in Episode 4. If the wall only exists in your application layer and someone writes a new database query that skips the check, the wall is breached. You need enforcement at multiple layers. At the database level — row-level security policies or filtered views that exclude walled matters. At the API middleware level — every request for matter data gets checked before reaching business logic. At the UI level — walled matters don't appear in matter lists, document views, or navigation. And at the search index level — this is the one people miss.

Dan: Mm. The search index — that's the full-text search?

Alice: Right. Law firms need firm-wide search. Lawyers search across hundreds of matters to find precedent or prior work product. But if a lawyer is walled off from a matter, the search results must not include documents from that matter. Not even snippets. Not even metadata like the document title. And here's the critical detail — the system should not indicate that results were suppressed. If a lawyer searches for "Acme Corp acquisition" and sees a message saying "two results hidden due to an ethical wall," they now know the firm is working on something involving Acme Corp on the other side. That itself is a confidentiality breach. The correct behaviour is silent suppression. The walled results simply don't appear.

Dan: Yeah, that's subtle but important. The absence of information is itself information.

Alice: Exactly. And this is why search is the hardest part of ethical wall implementation. You need to filter at query time, not just at display time. The search engine needs to know which matters each user is walled from and exclude those documents before generating results.

Dan: Mm. What about audit? You mentioned the rules require proof that the wall works.

Alice: Your audit log needs to capture five things. When the wall was created, including the triggering conflict and who created it. Any modifications to the wall. Every access attempt where the wall was evaluated — both grants and denials. When the wall was removed, who authorised it, and certification that no breach occurred. And periodic attestations — quarterly or annual confirmation that the wall is still in place. These logs have to be immutable. Once written, nobody can edit or delete them — not even the firm administrator.

Dan: Right. Because if the admin could delete the logs, the proof disappears.

Alice: Precisely. And courts have taken this seriously. In the UK, the case of Petter v EMC Europe in 2015 examined whether an information barrier at a law firm was sufficient. US courts have disqualified firms where screens were found to be "paper screens" — documented procedures that weren't actually enforced in practice. Software-enforced walls with access logs provide much stronger evidence than policy documents alone.

Dan: Mm. So for anyone building legal SaaS — ethical walls aren't a feature you can add later. They need to be baked into the data model from the start.

Alice: Right. Matter-scoped access is the foundation. Every query must be scoped to the user's matter assignments. Ethical walls add a deny layer on top. Dynamic conflict checking triggers walls automatically. Silent search suppression prevents metadata leakage. And immutable audit logs prove it all works. If you're building legal SaaS and you don't have this — your enterprise law firm clients will find out during the security assessment, and the deal is over.

Dan: Next episode — Zero Trust Architecture. The security model that says nothing should be trusted by default, whether it's inside your network or outside it.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.