Security Productivity Balance for B2B Firms

Getting the security productivity balance right is one of the hardest operational problems a B2B services firm faces. Lock everything down and your team grinds to a halt. Leave things open for the sake of speed and you're one phishing click away from a month-long nightmare. I've watched business owners on both ends of this spectrum, and neither extreme serves them well.

The answer isn't splitting the difference. It's building a strategy that matches your actual risk profile, prioritizes detection and recovery over pure prevention, and communicates expectations clearly enough that every person on your team understands their role. That's the framework I want to walk through here.

---

What Does "Security Productivity Balance" Actually Mean for a Services Firm?

The security productivity balance refers to the operating point where a firm's protective controls are strong enough to manage real risk without creating friction that kills team output or slows client delivery.

Think of it as a dial. All the way toward security and you've got employees needing three authentication steps to send a Slack message. All the way toward productivity and someone's reusing the same password across six platforms and clicking every link that lands in their inbox. Neither works. The goal is finding the setting that matches your specific risk, not following a generic checklist.

Two definitions matter here. "Detection and response" is the practice of monitoring your environment for abnormal activity and having a plan to act on it, rather than relying solely on preventing intrusions in the first place. "Business continuity" is your documented ability to keep operating, even in a degraded state, while a security incident is being resolved. Both concepts underpin everything else I'll cover.

The old security model was purely about prevention: build walls high enough that attackers can't get in. That thinking is obsolete. Security strategist Bruce Schneier has argued publicly that prevention alone is no longer achievable, and that detection and response are now the primary posture. I think he's right. The implication for services firms is significant because it shifts where you invest time and money.

---

Why Do Most B2B Services Firms Get This Wrong?

Most B2B services firms underinvest in security until something breaks, then scramble reactively. The "I'll deal with it when it's a problem" mindset is the default, and it's expensive.

I've worked with and spoken to enough business owners to know this pattern cold. Security isn't their business. They're running a law firm, a software shop, a manufacturing operation. The security problem feels abstract right up until it isn't. And when something does go wrong, the average organization is now down for roughly 30 days. A month. Not a weekend. Thirty days of degraded or halted operations.

I remember a story from early in my own experience running a business: a CIO was trying to get budget approved for network infrastructure that kept going down. The CEO pushed back on the cost. The CIO came back with a number showing the firm was losing $15,000 per hour during outages. That conversation ended quickly. The math on downtime almost always justifies the investment in prevention and recovery infrastructure, but you have to do the math first.

The AT&T outage from a few months ago is a clean case study in third-party risk. Businesses that ran their entire payment processing through AT&T went dark during the outage. Restaurants had to close during their busiest hours because they couldn't process cards. The Change Healthcare breach hit nearly every downstream healthcare provider that used their platform. These aren't hypotheticals anymore. Third-party dependency is now a primary attack surface.

The other reason firms get this wrong is that they treat security as an IT problem rather than a business problem. That's the wrong frame. If your systems go down, that's a revenue problem. If client data leaks, that's a liability and reputation problem. Security decisions belong at the leadership table, not just in the server room.

---

How Should You Audit Your Own Security Before Bringing in Help?

Start by documenting what data you hold, who might want it, where it lives, and what controls you currently have in place. That basic inventory puts you ahead of most firms your size.

Here's the practical sequence I'd recommend. First, identify three to seven core processes in each business department. Then map the applications that support each of those processes. That gives IT a clear picture of what needs to be protected and, critically, what needs to stay operational if something goes wrong. You've just handed them a business requirements document, which is something most IT teams never get from the business side.

Second, get honest about your tolerance for downtime and data loss. If your billing system goes dark, how long can you function? Two hours? Two days? That tolerance number drives almost every infrastructure decision downstream: backup frequency, redundancy investment, recovery prioritization. Without it, you're guessing.

Common misconfigurations are the low-hanging fruit. Humans configure systems, humans make mistakes, and those mistakes compound over time. An annual review of firewall rules, endpoint settings, and access permissions will turn up issues that seem embarrassing in retrospect but are completely normal. I've seen it enough to know that finding them is not a sign of incompetence; it's a sign of a functioning review process.

Multifactor authentication (MFA) is the single highest-ROI control most firms aren't using consistently. It slows attackers down significantly. But even MFA has a failure mode: when people become so conditioned to accepting push notifications that they approve them without thinking. Getting an MFA prompt at 7pm when you've been home for two hours and haven't touched a work system should trigger a pause. It usually doesn't. That's a training gap, not a technology gap.

---

What Does a Practical Security Productivity Balance Look Like in Practice?

The right balance means applying controls proportional to the sensitivity of each system, not applying the same level of restriction across everything.

Not every employee needs the same controls. Someone in accounting with access to financial systems carries a different risk profile than someone in marketing scheduling social posts. Engineering teams accessing client infrastructure sit in a different tier than customer service. The controls should reflect that. Applying maximum friction uniformly destroys productivity for people who don't need it and breeds resentment that leads to workarounds, which are often worse than the original risk.

Here's a comparison of the two common approaches:

The risk-tiered model wins. It's not the easiest to implement, but it's the only one that holds up.

On the communication side: security policy needs to be a top-down mandate, not an IT memo. When I ran a business, we used public accountability in our internal Slack channel to drive MFA adoption. Anyone who hadn't turned on two-factor authentication for their email got called out, with memes and animated GIFs, until we hit 100% compliance. It worked. It won't work everywhere (probably not at a law firm), but the underlying principle does: leadership has to own it and the organization has to understand the "why," not just the "what."

Policy matters, but it can't be the only mechanism. Most people don't read updated employment agreements carefully, and a one-time policy document isn't training. Consistent delivery through a learning management system, combined with simulated phishing exercises that are immediately followed by actual instruction (not just a "gotcha"), is how you build real organizational awareness. The goal isn't to embarrass people; it's to teach them the six to eight things to look for in an email that signal it's not legitimate.

---

How Should You Think About AI's Role in Security Threats and Defenses?

AI has made phishing attacks significantly harder to spot and has accelerated the scale at which attackers operate, but the most common entry points are still remarkably simple.

The most sophisticated attackers can now train AI on a CEO's writing style, email cadence, and vocabulary and send convincing impersonation emails at scale. That's real and it's happening. But the bulk of successful attacks still come through basic phishing links, weak passwords, and MFA approval fatigue. AI amplifies the threat volume; it doesn't change the fundamental mechanics of how most breaches begin. Someone clicked a link.

The "use AI to fight AI" argument has merit at the platform level. Many modern security tools have used machine learning for anomaly detection for years (often marketed under different names, but the underlying approach is similar). Managed Detection and Response (MDR) providers use these tools to monitor network traffic and flag abnormalities in real time. That layer of monitoring is increasingly accessible even for mid-market firms that can't justify a full internal security team.

The arms race framing is accurate though. Adversaries are organized, well-funded, and operate like corporations with QA processes and product development cycles. I've heard Chris Cathers, a security specialist I spoke with recently, describe this in exactly those terms. Outspending them on prevention isn't realistic for most firms. So the smarter question isn't "how do I keep them out forever?" It's "how do I detect them quickly, contain the damage, and keep the business running while I recover?"

That reframe changes everything about how you allocate your security budget.

---

What Should Your Security Recovery Plan Actually Include?

A recovery plan needs to document who gets notified, in what order, what systems get restored first, and how the business operates while systems are down. Without documentation, recovery becomes improvisation under pressure.

The 30-day downtime average is the number most business owners find shocking. When I first heard it, I understood why: most firms have not thought seriously about operating for a month without their primary systems. What would you do? How would you bill clients? How would you communicate internally? How would you deliver work?

Early in one of my businesses, the first security process we put in place was a communication plan for breaches: who gets notified, who doesn't need to know yet, and who is responsible for coordinating response. That foundation was more valuable than almost any technical control we put in later, because it meant that when something went wrong, there was no scramble to figure out who was in charge.

A recovery plan has four components worth documenting: the notification chain, system restoration priorities (which processes must come back first), backup verification (not just that backups exist, but that they're actually recoverable), and an analog fallback for operations. That last one sounds archaic until you need it. If your card processing goes down, what do you do? If your project management system is inaccessible, how does the team coordinate? The restaurant that closed during the AT&T outage because it had no plan B is a case study in why this matters.

Virtual CISO engagements (where an external security advisor fills the strategic security leadership role without a full-time hire) are one of the more accessible options for mid-market services firms. They bring cross-industry perspective on what controls are appropriate at your size and risk level, and they can help you build the roadmap without requiring you to become a security expert yourself. It's a more proportionate model than either ignoring the problem or hiring a full security team. fractional executive models

---

Key Takeaways

• The security productivity balance isn't about choosing one over the other; it's about applying controls proportional to the risk level of each system and role.
• Prevention alone is no longer a viable strategy. Detection, response, and recovery are now the primary posture.
• The average organization is down 30 days after a significant attack. If you haven't modeled what that costs you, you haven't made a real investment decision yet.
• Most successful breaches start with something simple: a phishing click, an approved MFA push notification, a misconfiguration. Sophisticated zero-days are the minority.
• A communication and notification plan should be the first security document your organization produces, before any technical controls.
• Third-party risk (AT&T, Change Healthcare) is now as real as internal risk. Your continuity plan needs to account for vendor outages, not just your own systems.

I covered this topic in depth on The Schmidt List, including a conversation about how mid-market firms can build security infrastructure that doesn't require a full-time CISO.

The question I'd leave you with: if your primary business systems went dark tomorrow for 30 days, what exactly is your plan for day two?