Rule of Thirds: Why Your All-Technical Security Team Is Failing

You built a team of specialists. Every one of them can read a packet capture, tune a SIEM rule, or explain the MITRE ATT&CK framework in their sleep. On paper, it looks like a strong security organization. In practice, your budget requests keep getting cut, your board presentations land flat, and your vendors are running circles around you in contract negotiations. The problem is not your team's technical depth. The problem is that technical depth is all you have.

The Rule of Thirds is a staffing model that security leaders who have built mature programs tend to arrive at independently, usually after one painful budget cycle too many. The idea is simple: roughly one third of your security team should be technical specialists, one third should be risk and governance advisors, and one third should be operational generalists who translate between the two. Most teams are 80 to 90 percent technical specialists. That imbalance is not a strength. It is a structural liability.

This is not an argument against technical excellence. Your specialists are irreplaceable. But a team that can only speak in technical terms cannot defend its budget in a board meeting, cannot negotiate a vendor contract from a risk posture, and cannot build the internal relationships that make security a business function instead of a cost center. If your team cannot translate what they do into business outcomes, someone else will translate it for them, and that translation will not favor your budget.

The model is not a rigid org chart. It is a capability framework. In a 12-person security team, you are looking at roughly four technical specialists handling detection, response, and engineering; four risk and governance advisors managing compliance, vendor risk, and policy; and four operational generalists who run the program, manage stakeholder relationships, and own the metrics that matter to leadership above you.

In smaller teams, one person often covers two roles. A 6-person team might have two specialists, two generalists, and two people who split risk advisory duties with operational work. The ratio matters more than the headcount. What you are measuring is whether your team has the capability to operate in all three modes, not whether you have three distinct job titles.

The failure mode is almost always the same. Teams hire for technical skills because those skills are easy to evaluate in an interview. Risk advisory and business translation skills are harder to assess, so they get deprioritized. Five years later, you have a team that is technically excellent and organizationally invisible.

Your board does not approve budgets based on CVE counts or mean time to detect. They approve budgets based on risk narratives they can understand and business outcomes they can measure. If your budget request arrives as a list of tool renewals and headcount asks without a risk-adjusted business case, it will get cut. Every time.

Risk and governance advisors are the people who build those business cases. They know how to translate a threat landscape into financial exposure. They know how to frame a $400,000 tooling investment as a risk transfer decision, not a technology purchase. Most all-technical teams do not have anyone who can do this work at the level the CFO and board require.

The math is straightforward. A single risk advisor who can defend a $2 million security budget in front of a skeptical CFO pays for themselves in the first budget cycle. That is not a soft benefit. That is a direct return on a hiring decision.

Enterprise security vendors have dedicated sales teams, renewal specialists, and pricing analysts whose full-time job is to maximize contract value. Your technical specialists are negotiating against them part-time, between incidents, without a clear understanding of your risk posture or your walk-away position. That is not a fair fight.

A risk advisor who understands your vendor portfolio, your compliance dependencies, and your switching costs can negotiate from a position of actual leverage. They know which contracts you can exit, which vendors have competitive alternatives, and which renewals are genuinely critical versus merely convenient. That knowledge is worth real money. Typical enterprise security contracts have 15 to 25 percent negotiating room that most teams never capture.

That vendor's TCO calculator conveniently leaves out integration costs, internal engineering time, and the opportunity cost of locking into a three-year term. Someone on your team needs to catch that before you sign, not after.

Your board asks how you measure ROI on security tooling. Your technical lead answers with detection coverage percentages and false positive rates. The board nods politely and moves on. Nothing changes. The problem is not that your technical lead gave a wrong answer. The problem is that nobody on your team owns the translation from technical metrics to business metrics.

Operational generalists and risk advisors own that translation layer. They take your MTTD and MTTR numbers and convert them into business impact language: downtime cost avoided, regulatory exposure reduced, cyber insurance premium implications. Those are the metrics that move budget conversations.

Most boards are not asking for a security briefing. They are asking for a risk briefing. There is a meaningful difference. A security briefing tells them what your tools do. A risk briefing tells them what the business is exposed to and what you are doing about it. Only one of those formats produces budget approval.

That quarterly access review is a ritual your team dreads and your auditors love. Neither group is asking whether it actually reduces risk. When technical specialists own compliance programs, they tend to optimize for audit pass rates rather than control effectiveness. The result is ceremonial security: documentation that satisfies a framework requirement without changing the actual risk posture.

Risk and governance advisors approach compliance differently. They ask which controls are actually reducing risk, which ones are theater, and where the framework requirements map to real business exposure. That perspective produces compliance programs that are both audit-ready and operationally meaningful.

SOC 2, ISO 27001, NIST CSF: these frameworks are tools, not destinations. A team with strong risk advisory capability uses them to structure a real security program. A team without that capability uses them to produce a binder that sits on a shelf until the next audit.

You probably cannot hire six new people to rebalance your team overnight. The practical path is to identify which of your current specialists have the aptitude and interest to develop risk advisory or operational skills, and invest in that development deliberately. Some of your best technical people are already doing informal risk translation. They just are not getting credit or support for it.

For the capabilities you cannot develop internally, targeted contract resources are often more cost-effective than full-time hires. A fractional CISO or a part-time GRC advisor can fill the risk advisory gap while you build internal capacity. This is not a permanent solution, but it is a realistic bridge for teams operating under headcount constraints.

When you do hire, change your evaluation criteria. Stop assessing every candidate primarily on technical depth. For generalist and risk advisory roles, evaluate communication skills, business acumen, and the ability to explain complex risk concepts to a non-technical audience. Those skills are harder to find and harder to develop than technical certifications.

The leading indicators of team imbalance are visible before the budget cycle hits. Watch for these signals: security budget requests that get cut without explanation, vendor contracts that auto-renew without negotiation, board presentations that produce no follow-up questions, and compliance programs that pass audits but generate no internal process improvements.

The lagging indicators are more painful. A security program that cannot grow its budget year over year despite a worsening threat landscape is a program that has lost the business case argument. That is almost always a team composition problem, not a technical problem.

Set a simple benchmark. After every board presentation, ask whether the board asked substantive questions about risk and business exposure. If the answer is consistently no, your translation layer is broken. Fix the team before you fix the deck.

Most security leaders build teams by backfilling technical roles as they open. Someone leaves, you hire a replacement with similar skills. The team composition never changes because the hiring process never changes. That approach produces a team that is optimized for the work it has always done, not the work the business actually needs.

The right way is to audit your team's capabilities against three dimensions before every hiring decision: technical depth, risk advisory capacity, and operational translation ability. Score each dimension on a simple 1 to 5 scale. Hire to close the lowest-scoring gap, not to replace the most recent departure. This takes discipline, especially when a technical role opens and the path of least resistance is to hire another specialist.

A team that scores 4 or 5 on technical depth but 1 or 2 on risk advisory and operational translation is not a strong team. It is a technically capable team that is organizationally fragile. One budget cut, one board presentation that lands badly, one vendor negotiation that goes sideways, and the fragility becomes visible.

The Rule of Thirds is not a theory. It is a pattern that emerges from security programs that have learned to operate as business functions rather than technical departments. Your specialists are not the problem. The absence of the other two thirds is. Start with an honest audit of your current team's capabilities across all three dimensions. Identify the gaps. Fill them deliberately, whether through hiring, development, or contract resources. Then measure the outcome where it matters most: budget approval rates, board engagement, and vendor contract value. Those are the metrics that tell you whether your security program is actually working as a business function, or just as a very expensive technical operation.