In the first article of our The Business of Security series, we discussed the five questions every law firm should ask technology vendors. In the second, we explored why compliance and real security maturity are not the same thing. Both topics point back to a broader theme that I’ve found gets overlooked surprisingly often.
Most organizations think security is a technology problem. It isn’t. At least, not primarily.
After spending years building and evaluating security programs, I’ve become convinced that security is fundamentally an operations problem. Technology certainly plays a role, but the organizations that consistently manage risk well are rarely the ones with the flashiest tools. They’re the ones whose day-to-day operations make good security outcomes the natural result of how the business functions.
This distinction changes the leadership conversation. Security stops being treated as a technical function tucked inside IT and becomes part of how the firm keeps client service moving when something goes wrong.
Security Exists to Protect the Business
I’ve sat in plenty of conversations where security discussions became buried in technical terminology. Vulnerability scans, identity controls, encryption standards, attack surfaces, and threat intelligence all matter, but executive teams can struggle to connect those concepts to the business outcomes they’re responsible for delivering.
The reality is that cyber risk is simply another form of business risk. The most effective leaders understand security in the same way they understand financial risk, operational risk, or legal risk. The question is not whether a vulnerability exists. The question is what happens to the business if that vulnerability is exploited. Can revenue-generating activities continue? Will employees be able to serve customers? How much downtime is acceptable? What would recovery actually cost?
I’ve always believed security teams need to speak the language of business rather than the language of technology. Telling an executive that a system contains a critical vulnerability may be technically accurate. Explaining how the same vulnerability could prevent lawyers from accessing client matters for three days creates a much different conversation. One is a technical observation. The other is a business impact statement.
Organizations that manage security effectively understand this distinction. They don’t treat security as a separate objective. They treat it as a mechanism for protecting the organization’s ability to deliver on strategic goals. When viewed through that lens, security becomes much easier for leadership teams to prioritize because they can clearly see what is being protected and why it matters.
Operational Friction Usually Starts Somewhere Else
One of the lessons I’ve learned from reviewing technology vendors over the years is that security problems rarely stay security problems for very long.
Instead, they become operational problems. A vendor experiences an outage, and attorneys can’t access critical systems. A software provider delays a major update without communicating timelines, and business workflows grind to a halt. A breach occurs at a third party, and suddenly firm leadership is spending days answering questions from clients, employees, and stakeholders instead of focusing on the business. What starts as a technology issue ultimately shows up as lost productivity, delayed work, frustrated users, and unexpected costs.
This is why vendor risk management deserves attention from business leaders, not just IT teams. Every vendor with access to firm data becomes part of the firm’s operational ecosystem. Their controls, processes, and recovery capabilities influence our ability to operate whether we realize it or not. A vendor’s risk eventually becomes our risk, and if something goes wrong, our clients are unlikely to care whose logo appeared on the compromised system. They only know their experience with our organization was impacted.
The most mature organizations recognize this connection and evaluate vendors accordingly. They don’t just ask whether a platform has the functionality they need. They ask how the vendor manages incidents, how communication happens during disruptions, and how quickly operations can recover when something inevitably does go wrong. Those questions are ultimately less about technology than they are about business continuity.
Resilience Is an Operational Capability
Many security conversations focus almost exclusively on prevention. The thinking is understandable. Stopping bad things from happening sounds preferable to dealing with them afterward.
The problem is that prevention has never been perfect.
Every organization connected to the internet will eventually face an outage, a failed process, a vendor issue, a security incident, or some other unexpected disruption. What often separates resilient organizations from struggling ones is not whether the event occurred. It’s how quickly normal operations can be restored afterward.
This is why I pay close attention to operational resilience. Do backups actually restore? Has the incident response process been tested? Have recovery procedures been rehearsed? Does leadership understand its role during a crisis? These questions may not seem as exciting as discussions about emerging threats or advanced technology, but they tend to matter far more on a bad day.
Organizations sometimes assume resilience is something that can be purchased. In reality, resilience is built through preparation, testing, and repetition. A documented recovery process that has never been exercised provides comfort right up until the moment someone needs to use it. Mature organizations validate their assumptions before the crisis arrives rather than during it.
The Martial Arts Problem
People often assume that strong security programs rely on sophisticated technology, secret techniques, or advanced capabilities that only experts understand.
I’ve found the opposite is usually true. Martial arts instructors often spend years teaching students the same basic movements. New students generally want to learn the advanced techniques. The instructors keep bringing them back to fundamentals. Eventually, students discover that mastery doesn’t come from knowing thousands of complicated moves. It comes from executing the basics exceptionally well, repeatedly, under pressure.
Security follows the same pattern. The strongest programs I’ve encountered are rarely distinguished by a secret security sauce. Instead, they consistently execute the fundamentals. They manage access appropriately. They enforce multi-factor authentication. They review permissions. They test backups. They patch systems. They conduct due diligence on vendors. They maintain visibility into their environment. None of these activities are particularly glamorous, but together they form the foundation of a mature program.
The organizations that struggle with security are often struggling with operations first. Processes aren’t documented. Ownership is unclear. Responsibilities are inconsistent. Visibility is limited. Security weaknesses emerge because operational discipline is missing. Conversely, organizations with strong operational habits tend to build stronger security outcomes almost naturally because the underlying processes support both objectives.
The Question Leaders Should Be Asking
One of the most common questions executives ask is whether their organization is secure. Like many simple questions, it’s not particularly useful. No organization is completely secure, just as no organization is completely free from financial, legal, or operational risk. A more productive question is whether the organization understands the risks it carries, has deliberately chosen which risks are acceptable, and can continue operating when challenges inevitably arise.
When leaders view security as an operational discipline rather than a technical specialty, the conversation becomes significantly clearer. The focus shifts toward protecting revenue, reducing friction, strengthening resilience, and ensuring the business can continue delivering value regardless of what happens. Those are outcomes every executive understands, whether they have a technical background or not.
Ultimately, the strongest security programs don’t succeed because they possess better marketing, more certifications, or more complicated technology. They succeed because they do the basics consistently, align security decisions with business objectives, and build operational habits that hold up on an ordinary Tuesday as well as they do on the organization’s worst day.
Next in the Business of Security Series
The Shared Responsibility Gap: What Law Firms Need from Their Technology Providers
