Over the last several articles in our The Business of Security series, we’ve talked about vendor due diligence, security maturity, and why security is fundamentally an operational discipline rather than a technology problem. Each of those topics ultimately leads to another area that creates a surprising amount of confusion within law firms and technology organizations alike: the shared responsibility model.
Most people have heard the term before. That’s not the problem.
The problem is that many organizations hear “shared responsibility” and interpret it as “someone else is handling most of this.” In reality, some of the most expensive security incidents I’ve seen have occurred precisely because neither side was completely clear on where the line of responsibility actually existed.
The misunderstanding reminds me of a tenant who comes home to discover their apartment has been burglarized. They immediately blame the landlord because the building was supposed to be secure. The landlord points out that the front door, security cameras, and perimeter controls all functioned exactly as intended. Then someone notices the tenant left a window unlocked for three days because locking it was inconvenient. Both parties are telling the truth, and yet the break-in happened anyway. The problem wasn’t on one side of the relationship. It existed in the gap between responsibilities that neither person fully understood until it was too late.
That gap exists in SaaS and cloud environments every day.
What Your Technology Provider Is Responsible For
One of the reasons SaaS platforms have become so popular is that they genuinely remove a significant amount of operational burden from customers. Technology providers are responsible for securing the infrastructure that powers the service. They manage data centers, maintain the underlying platform, monitor networks, patch systems, and invest heavily in the security controls that protect the environment they operate. In many cases, they also manage encryption, maintain compliance certifications, and continuously monitor the services under their control.
These things matter because they are difficult, expensive, and highly specialized. Most law firms do not want to build and operate secure data centers or maintain teams dedicated solely to monitoring infrastructure around the clock. SaaS providers can perform those functions at a scale that would be impractical for individual organizations to replicate themselves.
This is where many discussions about shared responsibility stop, and that’s where the confusion begins.
A vendor can do an excellent job securing its environment and still leave a customer exposed if the customer fails to manage the responsibilities that remain on its side of the relationship. The provider secures the building. The firm is still responsible for what happens inside the office.
What Your Law Firm Is Responsible For
The responsibilities that remain with the customer are often broader than people expect.
Identity management is one of the biggest examples. The vendor may provide multi-factor authentication capabilities, but the law firm is typically responsible for deciding whether those controls are required, who receives access, what permissions users have, and how quickly access is removed when someone changes roles or leaves the organization. A surprisingly large number of security issues begin with weaknesses in these administrative processes rather than failures within the technology platform itself.
The same is true for data governance. Technology platforms generally do not know which files are confidential client records, which documents contain personally identifiable information, or which information would create regulatory obligations if exposed. The firm determines how data is classified, who can access it, and how it should be handled throughout its lifecycle. Those decisions remain business decisions regardless of where the data is stored.
Business processes also play a significant role. User provisioning, approval workflows, password practices, security awareness efforts, vendor administration, and change management procedures all influence risk. While these activities may not appear particularly technical, they often determine whether security controls succeed or fail in practice. A mature security program depends just as much on operational discipline as it does on technology.
The Risk Doesn’t Stop at the Vendor Boundary
One of the most useful observations executives can make is recognizing that vendor risk and business risk are often the same thing.
When a law firm adopts a SaaS platform, the technology provider becomes part of the firm’s operational ecosystem. If a vendor experiences an outage, clients may be affected. If access controls are misconfigured, confidential information may be exposed. If backups are not properly managed, recovery efforts may become complicated when they’re needed most. The resulting disruption rarely distinguishes between whose responsibility the issue technically was. From the client perspective, the firm’s operations were impacted.
This is particularly important because the dividing line between provider responsibilities and customer responsibilities is not always identical from one vendor to the next. Different platforms assign different obligations to their customers, and assumptions are often where mistakes begin. Organizations that manage this well avoid assuming where the line exists. Instead, they make a deliberate effort to understand it.
The Questions Leadership Should Be Asking
One of the recurring themes throughout this series has been that leadership does not need to become deeply technical in order to make good decisions. The same principle applies here.
Rather than asking, “Who owns security?” leaders often get more useful answers by asking questions like:
- “Who owns this specific responsibility?”
- “Who is accountable for user access reviews?”
- “Who is responsible for enabling and enforcing multi-factor authentication?”
- “Who owns data classification decisions?”
- “Who verifies backups can actually be restored?”
- “Who reviews vendor changes that could affect firm operations?”
These questions move the conversation away from broad concepts and toward accountability. Security programs become stronger when ownership is explicit rather than assumed. In my experience, problems rarely occur because no one cared. They occur because everyone believed someone else was handling it.
Leadership should also ask how responsibilities are documented and communicated. Most major technology providers publish shared responsibility guidance, but many organizations do not review those materials until after an incident has occurred. Understanding where the line sits during vendor selection is considerably easier than trying to determine it during a crisis.
Accountability Is the Real Shared Responsibility Model
The phrase “shared responsibility” sometimes creates the impression that responsibility itself is divided equally between provider and customer.
The reality is more nuanced than that.
Responsibility is shared, but accountability must be explicit.
Technology providers should be accountable for securing the systems and services they operate. Law firms should be accountable for governing access, managing users, protecting data, and ensuring business processes support secure operations. The most successful partnerships emerge when both sides clearly understand where those responsibilities begin and end.
Ultimately, the goal is not to determine whether a vendor is responsible for security or whether the law firm is responsible for security. The answer is both. The more useful question is whether everyone understands which specific responsibilities belong to whom and whether those responsibilities are being actively managed. The organizations that answer that question well tend to avoid the gaps where most security incidents begin.
Read the next article in our The Business of Security series: The First 24 Hours: How Strong Organizations Manage Incidents and Protect Trust.
Next in The Business of Security Series
The First 24 Hours: How Strong Organizations Manage Incidents and Protect Trust
