A legal operating model is the structure that sets how an in-house legal team delivers legal services: which work it owns, who does it, how requests move, who decides and which systems support it. It rests on five components: people, process, governance, data and technology. Build the model first. A Legal OS can only encode decisions the legal operating model has already made.
Operational efficiency is the number one strategic initiative for chief legal officers this year. It was identified as a top priority by 53% of CLOs questioned in the 2026 ACC Chief Legal Officers Survey, ahead of regulatory compliance at 39% and technology implementation at 38%. But where does efficiency come from?
Efficiency depends first on how a department is organized, not on what it installs. That makes it a legal operating model question before it is a technology question. The pressure is particularly high at a time when legal teams are not growing at the same pace as their workload.
Many teams keep buying tools that each solve part of the problem, but the truth is that no system can decide on the ways of working: who owns what, when and why.
For the tech to work, and for adoption to follow, the legal function needs to understand the change it is looking for and what that means for the entire organization. A system can encode a way of working, but it cannot invent one.
What is a legal operating model?
A legal operating model is the structure that determines how an in-house legal team delivers legal services to the business. It sets:
- Which work the function owns
- Who does that work
- How requests move through it
- Who holds which decisions
- What systems all of it runs on
It also defines how the legal department works with the other business functions it serves.
Legal operating model vs. legal entity operating model
The concepts of legal operating model and legal entity operating model are often confused.
- A legal operating model describes how the legal function works.
- A legal entity operating model, a tax and corporate governance term, is the blueprint for how a group’s entities are structured and connected.
A target operating model, or TOM, is a legal operating model described as a future state rather than the current one. Everything below concerns how the function works.
Centralized, embedded or hybrid: The three legal operating model structures
Legal operating models come in three structures, separated by where the lawyer sits relative to the business. Each buys something and gives something up.
| Structure | What it gives you | What it costs you |
|---|---|---|
| Centralized | Consistent standards, capacity you can see and reallocate | Distance from the commercial conversation, legal arriving late to deals |
| Embedded | Lawyers inside the business units, with context and speed | Standards drifting between units, duplicated effort nobody notices |
| Hybrid | A central core for standards, embedded specialists for proximity | Coordination overhead, ambiguity over who owns a borderline request |
Many large organizations land on hybrid because they need consistency and proximity at once. There is no right or wrong choice, the model will depend on the business’s needs, structure and capabilities. To choose the right model, legal leaders and GCs should assess five components that will shape everything that follows.
The five components of a legal operating model
A legal operating model is built on five components: people, process, governance, data and technology. The first three determine how the function works; data shows how well they work, and technology puts the model into practice.
If these five elements do not align, no tool or change management strategy will help the legal function work cohesively with the rest of the organization. When legal intake paths, approval guidelines or escalation rules are not defined, anything configured around them rests on guesses.
People
People means considering composition before headcount. The first sourcing decision is what stays in-house, what goes to outside counsel, what moves to an alternative provider, and what should be automated. That answer belongs in the model rather than in the general counsel’s head, and it is usually maintained by a dedicated legal operations function.
Process
This is where GCs and legal leaders should identify the repeatable path work takes, from the moment a request reaches Legal to the moment when the work is completed . Most departments have written this down for litigation and nowhere else, which is why the same request sometimes takes three days or three weeks depending on who picks it up.
Governance
Here, governance means the legal department’s own decision rules. To establish a legal operating model, the rules behind routine and exceptional work need to be set: approval thresholds, a stated risk tolerance, and the line between what legal signs off and what the business can itself. Without them, every exception travels to the general counsel, which is what a delegation framework with escalation rules exists to prevent.
Data
Data shows whether people, process and governance are working. The starting point for legal ai data governance is ensuring the data is clean and ready to use. This is important because that defines what the team can measure. Start with cycle time by matter type, cost per matter, the share of spend going outside, and the proportion of requests arriving through a known channel. A cycle time nobody agrees how to measure is not a metric but an argument waiting to happen in front of the board.
Technology
Technology is the component that holds the other four in place. Intake forms, routing rules, templates and dashboards work when they encode decisions the legal operating model has already made about people, process, governance and data. Which layer that should be, and why it comes second, is the subject of the following section on why the technology should come after the legal operating model.
Building a legal operating model
Once the key components are clear, the question becomes how to build the model. It does not have to be a two- or three-year program; it can move faster if legal leadership and GCs understand the questions they need to answer. It starts by mapping how legal work moves and where the blockers are, then setting the proper decision rights, and finally assessing whether the team is mature enough to move to the tech implementation phase.
Step 1. Map how legal work moves and where it stalls
Map what the function does against what the business needs; the two are rarely the same. Start where work stops moving, not with the process as it should look on paper, and look at the handoffs first: legal to procurement, finance, the board secretariat, outside counsel. That is where cycle time piles up, and where the business forms its opinion of legal, because a deal sitting in review is visible to everyone waiting on it. Write the result as a service catalog: a delivery standard, a target turnaround and an owner for each request type.
Step 2. Set decision rights and governance that survive turnover
Mapping shows where work stalls; decision rights make sure the fix holds. Without them, the new process erodes the first time a deal team pushes back, and it survives only as long as the person who designed it.
The practical output is a decision-rights matrix built on top of the service catalog: for each request type, who approves, at what threshold, and who can override. Add the responsibiilty most departments forget, which is who owns the data, because somebody has to be accountable for the entity register and the contract repository staying current. Once the matrix is written down, a junior lawyer and the general counsel reach the same answer on the same facts.
Step 3. Think about the team’s maturity before choosing the tech
A team still standardizing intake and a team already reporting cycle time to the board cannot make the same jump in the same year. Maturity moves through stages: ad hoc, then standardized, then measured, then improved against what the measurement shows. Skip one and the next collapses. A department that has not standardized intake has nothing stable to measure, and a dashboard built on top of it reports noise with great precision. Ambition is cheap to plan and expensive to pay for, so a short readiness check is worth the hour.
Why the technology should come after the legal operating model
Any legal tool or platform repeats the decisions it was configured with and makes none of its own. Routing rules, approval thresholds and templates all have to come from somewhere, and the legal operating model is where they should come from.
When the legal operating model is settled, setting up the tool is mostly a matter of writing down decisions that already exist. When it isn’t, the people in the configuration workshop end up making those decisions. A project manager or a vendor consultant picks an approval threshold on the spot, and it becomes legal policy without the general counsel ever signing off.
A settled model also changes how a team buys. A department that knows its own process can hand vendors a real scenario: a contract approval that crosses procurement, finance and a business approver, shown end to end with the related entity and the obligation that follows. The team sees in a one-hour demo whether a platform can handle it, instead of finding out in month four. A department that cannot describe its process has nothing to test against, so it compares feature lists.
What does a Legal OS add once the legal operating model is in place?
Once the legal operating model has been chosen and put in place, a legal operating system, or Legal OS, is its natural companion. It is the connected layer underneath legal work. In this layer, contracts, entities, matters, obligations, approvals and decisions work together. Otherwise, they would sit in five systems that each know a fifth of the story.
It turns the decisions in the model into defaults. Standard work becomes a template library. The intake path becomes a form with routing rules, so it keeps working when someone is under deadline.
Get the legal operating model right and the technology follows
The work keeps growing faster than legal teams do, so the order of operations is what matters. The legal operating model decides what good looks like. The system makes good repeatable. Reverse the two and you have bought a precise answer to a question nobody wrote down.
DiliTrust works withsupportss legal departments at that second stage, once a function knows how it intends to operate and needs a connected system to hold it there. The first stage, building the legal operating model itself, is work only your own team can do.
Legal operating model FAQ
What is a legal operating model?
A legal operating model is the structure that determines how an in-house legal team delivers legal services to the business. It defines which work the function owns, who does that work, how requests move through it, who holds which decisions, and what systems all of it runs on. Also, it has five components: people, process, governance, data and technology.
What is the difference between a legal operating model and legal operations?
The legal operating model is the design: which work the function owns, who does it, how it moves and who decides. Legal operations is the discipline that builds and maintains that design. It covers process, data, vendors, budget and technology. A department can have a legal operating model without a dedicated legal ops professional. However, the model tends to decay without someone accountable for it.
Who owns the legal operating model?
The general counsel owns it, because the model encodes decisions about risk tolerance and resourcing that only the GC can make. Where a head of legal operations exists, they usually run the design work, gather the evidence and hold the process. Meanwhile, the GC signs off on decision rights and sourcing.
Which legal operating model is best: centralized, embedded or hybrid?
There is no best structure in the abstract. Centralized protects consistency and makes capacity visible. Embedded gives lawyers commercial context and speed inside a business unit. Hybrid combines a central core with embedded specialists and is where many large organizations end up. The right answer follows the shape of the business. It also follows the places where legal risk actually accumulates.
How long does it take to build a legal operating model?
Most of the work is decision-making rather than implementation, so the timeline depends on how quickly the function can agree. Teams that treat it as three steps, mapping how work moves, settling who decides and checking their maturity, can reach a workable first version without a multi-year program. Furthermore, refining it is continuous.
How does the legal operating model affect legal technology selection?
It determines what you are buying for. A department with a defined operating model can test a platform against a real end-to-end scenario. This includes handoffs, approvals and the records left behind. However, a department without one evaluates features. Then it configures the software around assumptions nobody has agreed to, which is how implementations stall after go-live.
