Information Barriers and Conflicts of Interest in a Client System
A conflict of interest policy that lives in a document and not in the permission model is a statement of intention, not a control.
Firms in law, accountancy, consultancy and advisory routinely serve clients whose interests conflict. The professional obligation is to keep the two engagements separated so that information from one cannot reach the team on the other. In most firms this obligation is discharged by a policy, a declaration and the professional judgement of the people involved, and the software knows nothing about it.
That arrangement fails in a specific and predictable way. Not through malice, but because a person who is on both engagements sees both, and the system that shows them both has no idea it should not. The remedy is to make the barrier a property of the system rather than of the individuals inside it.
What an information barrier actually is
An information barrier is an enforced separation between two bodies of work inside one organisation, such that a person cleared for one cannot access the other, and the fact of the separation is itself controlled. It differs from ordinary access control in three ways that matter to anybody implementing it.
- It is symmetrical and mutual. Two groups are separated from each other, rather than one group being granted access to something.
- It is often invisible: a person on the wrong side should typically not see that the other engagement exists, because the existence of a mandate can itself be sensitive.
- It must be auditable after the fact. The question a regulator or a court asks is not whether the barrier is in place today but whether it was in place, and honoured, on a particular date.
Where barriers leak in practice
The interesting failures are almost never a person opening a document they should not. They are the places where information escapes through a channel nobody classified.
- Search. A search result that returns a title, or merely a count of matches, discloses the existence of the engagement even when the document cannot be opened.
- Notifications and digests. A summary email assembled by a background process frequently runs with broader rights than the person receiving it.
- Global reporting. A firm-wide utilisation or pipeline report includes both engagements by construction, and it is normally nobody's job to check it against the barrier list.
- The resourcing view. A scheduler seeing who is booked to what learns the mandate exists, and schedulers are rarely on either team.
- Exports. A data extract taken for a legitimate purpose flattens permissions unless the export applies the same scoping as the screen it was taken from.
- Audit logs themselves, which record activity on both sides and are often readable by an administrator with no barrier applied.
Implementing it so it holds
Four properties distinguish a barrier that works from one that is documented.
- It is applied at the data layer, not the interface. Any control that only hides a screen is defeated by the first report, export or interface that was written afterwards.
- It defaults to denial. A new feature must be invisible to a barriered engagement until somebody has considered it, rather than visible until somebody remembers.
- Clearance is granted per person per engagement and is time-stamped, so the question of who was cleared on a given date has an answer.
- Every access decision it makes is logged, including denials. A denial log is what demonstrates that the barrier was doing work, and without it you can only show configuration.
Proving it, which is a separate exercise
A barrier is not a feature you can inspect; it is a property you can only demonstrate by attempting to violate it. Configuration review shows what was intended. Only an attempted access shows what happens.
The practical form of this is a standing test that, for each barrier, takes an identity cleared for one side and attempts every read path to the other: the record, the search index, the reporting endpoints, the exports, the notification digest. Each must deny, and each denial must be logged. This runs continuously rather than at review time, because the failure mode is a new endpoint added six months after the barrier was configured, and a review scheduled annually finds it up to a year late.
The same reasoning applies to tenant separation generally. Cross-tenant isolation is the same class of control with a different boundary, and the same rule applies: it is proven by attempting the access, not by reading the configuration.
The human side the software cannot cover
Technical enforcement handles the system and cannot handle the corridor. A person who has been on both sides at different times still knows what they know, and no permission model addresses that.
The controls that do are procedural: a conflict check before an engagement is accepted rather than after it has started, a recorded decision about whether a barrier is required, physical or scheduling separation of teams where the sensitivity justifies it, and a rule that a person moves between sides only through a documented process with a defined cooling period. These belong in the engagement acceptance process, which is the only point at which a conflict can still be declined cheaply.
What clients should be told
Clients in sectors where conflicts are common will ask how they are managed, and the answer should be specific. A firm that describes its policy is giving a weaker answer than one that describes the enforcement.
What can reasonably be said without disclosing another client's mandate: that separation is enforced in the systems rather than by convention, that clearance is recorded per person and dated, that access attempts including refused ones are logged, and that the enforcement is tested continuously rather than reviewed periodically. Each of those is checkable, which is what makes it worth saying.