Introduction
Most security teams are built by accident. A breach happens, headcount gets approved, and you hire the best technical talent you can find. Three years later you have a team of eight engineers who can reverse malware in their sleep but cannot explain a risk trade-off to a CFO without losing the room. That is not a talent problem. That is a structural problem.
The Rule of Thirds is a team composition model built on a simple observation: security programs fail not because they lack technical depth, but because they lack the other two thirds. One third of your team should be technical specialists. One third should be risk and governance advisors. One third should be operational integrators who translate between security and the business. Most teams are 80 percent the first category and zero percent the other two. The result is a program that is technically credible and organizationally invisible.
This article is for CISOs and VPs of Security who are staring at a team that works hard, ships good work, and still cannot get budget approved or influence architectural decisions before they are already locked in. The fix is not hiring more engineers. The fix is rebalancing the team you already have.
Browse the Full Cybersecurity Market: 118 Categories, 9,000+ Tools.
What an All-Technical Team Actually Costs You
The cost is not measured in salary. It is measured in decisions made without you. When your team cannot speak the language of the business, the business stops inviting you to the table. Product ships without a security review. M&A due diligence happens without your input. A new SaaS vendor gets approved because procurement did not know to loop you in.
That organizational invisibility compounds over time. Each missed conversation is a control gap that does not show up in your vulnerability scanner. It shows up 18 months later when you are explaining to the board why a third-party vendor had access to customer data and nobody flagged it during onboarding.
The all-technical team also creates a retention problem. Your best engineers get pulled into meetings they are not equipped for, asked to justify budget in terms they were never trained to use, and eventually leave for roles where they can just do the technical work. You lose the people you most wanted to keep.
The Three Roles Your Team Actually Needs
The Rule of Thirds is not about job titles. It is about functional roles that every mature security program requires, regardless of team size.
Technical Specialists are your depth. Incident responders, detection engineers, penetration testers, cloud security architects. They build and operate controls. In a 12-person team, you want roughly four people here. In a 6-person team, two. They should not be writing board reports or running vendor evaluations.
Risk and Governance Advisors are your translators. They speak fluent business and fluent security. They own your risk register, your compliance program, and your relationship with legal and finance. They are the ones who can sit in a budget meeting and explain why a $400K investment in identity governance reduces your cyber insurance premium by $200K and your breach probability by a measurable percentage. Most teams have zero people in this role.
Operational Integrators are your connective tissue. They own vendor relationships, security awareness, policy enforcement, and the day-to-day coordination between security and IT, engineering, and business units. They are not technical enough to be specialists and not strategic enough to be risk advisors. They are exactly what most teams are missing when controls fail silently because nobody was watching the handoff.
How to Diagnose Your Current Team Composition
Before you restructure anything, map what you actually have. For each person on your team, answer three questions: What do they produce? Who do they talk to outside the security team? What would break if they left tomorrow?
If the answers cluster around technical outputs, internal security conversations, and operational continuity, you have a technical-heavy team. That is not a criticism. It is a starting point.
A faster diagnostic: look at your last five budget requests. How many were approved on the first submission? How many required multiple rounds of revision because the business could not understand the risk justification? If the answer is more than two, you do not have a communication problem. You have a structural gap where a risk advisor should be sitting.
Rebalancing Without Blowing Up Your Headcount Budget
You do not need to hire three new people to fix this. Most teams can rebalance by developing existing talent and being deliberate about the next two hires.
Start with your next open role. Before you post a job description that asks for five years of SIEM experience and three certifications, ask what the team actually needs. If you already have four strong detection engineers, your next hire should be a GRC analyst who can own your risk register and talk to your CFO. That hire will unlock more budget than a fifth detection engineer ever will.
For existing team members, identify one or two people who already gravitate toward the business side. They attend the cross-functional meetings voluntarily. They ask questions about business impact, not just technical severity. Invest in them. Send them to a risk quantification course. Give them a seat at the vendor negotiation table. You are not retraining them. You are recognizing what they already are.
The math on team composition for common team sizes:
| Team Size | Technical Specialists | Risk/Governance | Operational Integrators |
|-----------|----------------------|-----------------|-------------------------|
| 6 people | 2 | 2 | 2 |
| 12 people | 4 | 4 | 4 |
| 20 people | 7 | 6 | 7 |
| 30 people | 10 | 10 | 10 |
These are targets, not mandates. A team of six with two strong risk advisors will outperform a team of twelve with zero.
What Happens to Board Reporting When You Fix This
Your board does not want a threat landscape briefing. They want to know three things: Are we more or less exposed than last quarter? What are we doing about the biggest risks? What do you need from us?
An all-technical team produces reports that answer none of those questions. They produce patch coverage percentages, mean time to detect metrics, and vulnerability counts. Those numbers are real and important. They are also meaningless to a board member who runs a manufacturing company and sits on your audit committee as a favor.
When you have a risk advisor on your team, board reporting changes. The metrics shift from operational to strategic. Instead of '94% of critical vulnerabilities patched within SLA,' you report 'Our residual risk from unpatched systems is concentrated in two legacy applications that we are retiring in Q3. The business impact of a breach in those systems is estimated at $2.1M. We are accepting that risk for 90 days.' That is a sentence a board can act on.
The Vendor Evaluation Problem Nobody Talks About
All-technical teams evaluate vendors on technical merit. That is the wrong primary criterion. The right primary criterion is whether the vendor solves a business problem at an acceptable cost and integration burden.
When your team runs a proof of concept, they test detection fidelity, API coverage, and query performance. They do not test whether the vendor's support model matches your team's capacity, whether the contract terms create lock-in that will hurt you in three years, or whether the total cost of ownership including integration, training, and ongoing tuning is actually lower than the incumbent.
An operational integrator who owns vendor relationships will catch those issues. They will also notice when a vendor's roadmap has quietly shifted away from the use case you bought them for. That is the kind of organizational intelligence that prevents the 'we spent $800K on a tool we barely use' conversation that happens in too many security budget reviews.
Entropy Is Real: Why Team Balance Degrades Over Time
Even if you build the right team today, it will drift. Technical specialists get promoted into leadership roles and stop doing technical work, creating a gap. Risk advisors leave for compliance roles at larger companies. Operational integrators get absorbed into IT when budgets tighten. Two years later you are back to an all-technical team and wondering why the program feels stuck.
Build a quarterly team composition review into your operating rhythm. It does not need to be formal. It needs to be honest. Ask: what functional gaps do we have right now? What decisions are being made without us? What would we do differently if we had one more hire?
The teams that maintain balance over time are the ones that treat composition as a strategic asset, not an HR exercise. They know that a team of ten with the right mix will consistently outperform a team of fifteen that is structurally misaligned.
Making the Case to Your CEO for a Non-Technical Security Hire
This is the conversation most CISOs avoid. You have budget for one headcount. Your CISO peers are hiring threat hunters. You want to hire a risk quantification analyst. Your CEO is going to ask why.
The answer is specific and financial. A risk quantification analyst who can model your top five threat scenarios in FAIR or a similar framework will produce a risk register that your CFO can use to make insurance decisions, your board can use to prioritize investment, and you can use to justify every security budget request for the next three years. That is a higher return on headcount than a sixth engineer who will spend 40 percent of their time on tickets.
Frame it as a force multiplier. The risk advisor does not replace technical capacity. They make the technical capacity you already have visible to the people who fund it. Without that translation layer, your best technical work is invisible to the people who decide whether it continues.
Frequently Asked Questions
At four or five people, you cannot have dedicated roles for each third. What you can do is assign functional ownership. One person owns risk and governance as a primary responsibility, even if they also do some technical work. The mistake small teams make is having everyone default to technical execution because that is what feels urgent. The risk function gets dropped entirely, and the team becomes invisible to leadership.
Conclusion
The Rule of Thirds is not a hiring formula. It is a forcing function for an honest conversation about what your security program actually needs to succeed as a business function. If your team is technically excellent and organizationally invisible, the problem is structural. The fix is deliberate. Start with your next hire, your next board report, and your next vendor evaluation. Ask whether the team you have is built to do the work, or just to do the technical work. Those are different things, and the gap between them is where most security programs quietly fail.
Stop Guessing About Vendor Health. Start Querying It with MCP.