Rule of Thirds: How to Structure a Security Team
Why an all-technical security team stays invisible to the business, and how to split yours into specialists, risk advisors and integrators.
Loading...
Why an all-technical security team stays invisible to the business, and how to split yours into specialists, risk advisors and integrators.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
A security team works best when about a third of it builds and runs controls, a third explains risk to the business, and a third keeps security connected to IT, engineering and the business units. If yours is nearly all engineers, you can usually fix most of it with your next one or two hires and the people who already lean toward the business side.
Browse the Full Cybersecurity Market. Every Category.
Every category on CybersecTools, from AI Security and Cloud Security to Threat Intelligence and Offensive Security. Filter by use case, industry, or company size.
Most security teams are built by accident. A breach happens, headcount gets approved and you hire the best technical people you can find, and three years later you have eight engineers who can reverse malware in their sleep but can't explain a risk trade-off to a CFO without losing the room. That isn't a talent problem. It is a structural one.
The Rule of Thirds starts from a simple observation, which is that security programs usually have enough technical depth and struggle because the other two thirds are missing. When a team works hard, ships good work and still can't get budget approved or shape architecture before it is locked in, it is usually because nearly everyone sits in the first group. The fix is to rebalance the team you already have before you hire more engineers.
What it costs you is decisions made without you, because once your team can't speak the language of the business, the business stops inviting you. Products ship without a security review, M&A due diligence happens without your input, and a new SaaS vendor gets approved because procurement didn't know to loop you in.
Over time that adds up, because each missed conversation is a control gap your vulnerability scanner will never show. It surfaces 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.
An all-technical team also has a retention problem. Your best engineers get pulled into meetings they aren't equipped for and asked to justify budget in terms they were never trained to use, and eventually they leave for roles where they can just do the technical work, which means you lose the people you most wanted to keep.
The Rule of Thirds is about functional roles every security program needs, whatever the job titles and whatever the team size.
Technical specialists are your depth: incident responders, detection engineers, penetration testers and cloud security architects who build and operate controls. In a 12-person team you want roughly four of them and in a 6-person team two, and they shouldn't be writing board reports or running vendor evaluations.
Risk and governance advisors are your translators, fluent in both business and security. They own your risk register, your compliance program and your relationship with legal and finance. They are the people who can sit in a budget meeting and explain, for example, how a $400K investment in identity governance could lower your cyber insurance premium by $200K and reduce your breach likelihood by an amount you can measure.
Operational integrators are your connective tissue. They own vendor relationships, security awareness, policy enforcement and the daily coordination between security and IT, engineering and business units. They aren't deep enough technically to be specialists or strategic enough to be risk advisors, and they are exactly who is missing when controls fail silently because nobody was watching the handoff.
Before you restructure anything, map what you actually have. For each person, answer three questions: what do they produce, who do they talk to outside security, and what would break if they left tomorrow?
If the answers cluster around technical output, conversations inside security and keeping operations running, you have a technical-heavy team. That is fine as a starting point.
A faster test is your last five budget requests. Count how many were approved on the first submission and how many needed several rounds because the business couldn't follow the risk case. If more than two needed rework, you have a structural gap where a risk advisor should be sitting.
You don't need three new hires to fix this. Most teams can rebalance by developing people they already have and being deliberate about the next two hires.
Start with your next open role. Before you post a job description asking 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 the risk register and talk to your CFO. That hire will win you more budget than a fifth detection engineer ever will.
Then look at your current people for the one or two who already lean toward the business side. They go to the cross-functional meetings without being asked and ask about business impact as well as technical severity. Invest in them: send them on a risk quantification course and give them a seat at the vendor negotiation table. You aren't retraining them so much as recognizing what they already are.
Targets for common team sizes:
| Team size | Technical specialists | Risk and governance | Operational integrators |
|---|---|---|---|
| 6 people | 2 | 2 | 2 |
| 12 people | 4 | 4 | 4 |
| 20 people | 7 | 6 | 7 |
| 30 people | 10 | 10 | 10 |
Treat these as targets rather than rules. A team of six with two strong risk advisors will do better than a team of twelve with none. If your team is smaller still, see building a governance program with a team of five.
Compare Cybersecurity solutions side by side
Features, integrations, NIST coverage and deployment for every Cybersecurity solution we list, in one table.
Your board doesn't want a threat landscape briefing. They want to know whether you are more or less exposed than last quarter, what you are doing about the biggest risks and what you need from them.
An all-technical team produces reports that answer none of that: patch coverage percentages, mean time to detect and vulnerability counts. Those numbers are real and they matter, but they mean little to a board member who runs a manufacturing company and sits on your audit committee as a favor.
With a risk advisor on the team, the metrics move from operational to strategic. Instead of "94% of critical vulnerabilities patched within SLA", you report something like "Our remaining risk from unpatched systems sits in two legacy applications we are retiring in Q3. We estimate the business impact of a breach there at $2.1M, and we are accepting that risk for 90 days." That is a sentence a board can act on. For more on this, see the security metrics your board cares about.
All-technical teams judge vendors on technical merit first. The better first question is whether the vendor solves a business problem at a cost and integration effort you can carry.
In a proof of concept, your engineers test detection quality, API coverage and query speed. What they usually don't test is whether the vendor's support model fits your capacity, or whether the contract terms will lock you in three years from now. They also rarely check whether the total cost, including integration, training and ongoing tuning, is really lower than the incumbent's.
An operational integrator who owns vendor relationships catches those issues, and also notices when a vendor's roadmap quietly drifts away from the use case you bought it for. That is what prevents the "we spent $800K on a product we barely use" conversation in a security budget review. For a fuller method, see how to choose enterprise cybersecurity products.
Even if you build the right team today, it will drift. Technical specialists get promoted into leadership and stop doing technical work, risk advisors leave for compliance roles at bigger companies, and 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.
So add a quarterly team composition review to your operating rhythm. It doesn't need to be formal, but it needs to name the real gaps: which functions are missing right now, which decisions are being made without you, and what you would do with one more hire. Teams that stay balanced treat composition as part of the strategy rather than an HR exercise.
This is the conversation most CISOs avoid. You have budget for one headcount, your peers are hiring threat hunters, and you want a risk quantification analyst, so your CEO will ask why.
Give a specific, financial answer. A risk quantification analyst can model your top five threat scenarios in FAIR or a similar framework. The result is a risk register your CFO can use for insurance decisions and your board can use to rank investment, and you can use it to justify every security budget request for the next three years. That is a better return on one headcount than a sixth engineer who will spend a large share of their time on tickets.
Present it as a multiplier. A risk advisor doesn't replace technical capacity. They make the technical capacity you already have visible to the people who fund it, and without that translation your best technical work stays invisible to the people who decide whether it continues.
Check a vendor before you sign
Mandos tracks funding, acquisitions, hiring and news for security companies. Look up any vendor on your shortlist before the renewal.
The Rule of Thirds is less a hiring formula than a way to force a clear conversation about what your security program needs to work as a business function. If your team is technically excellent and invisible to the company, the problem is structural and the fix is deliberate.
Start with your next hire, your next board report and your next vendor evaluation. Ask each time whether the team you have is built to do the whole job or only the technical part, because the gap between those two is where a lot of security programs quietly fail.
You can't have dedicated roles for each third at that size, but you can assign ownership. One person owns risk and governance as their main responsibility, even if they also do technical work. The mistake small teams make is letting everyone default to technical work because it feels urgent, which drops the risk function entirely and makes the team invisible to leadership.
Flip the framing. A board that only asks about technical threats has usually never had a risk-translated briefing, so your first risk advisor hire is partly an investment in educating the board. Show them one quarter of risk-quantified reporting and the conversation changes. The case for the hire is the quality of the conversation it makes possible, more than the compliance box it ticks.
This usually comes from a history of non-technical people making bad technical decisions, so address it directly. The risk advisor isn't there to override technical judgment. They are there to turn it into language that gets budget approved and decisions made. Most technical people come around once they see a risk advisor win a budget request they couldn't win on their own.
If you rebalance through attrition and deliberate next-hire choices, the extra cost is close to zero, because you are only changing the profile of a role you were going to fill anyway. If you add a new headcount, a mid-level GRC analyst or risk quantification specialist usually costs less than a senior detection engineer in the same market. Expect to see the effect on board reporting and budget approvals one to two quarters after the hire is onboarded.
Track three things: your budget approval rate on first submission, the number of cross-functional decisions where security had input before the decision was made, and how the board rates your quarterly briefings. These are lagging indicators, but they tend to move within two to three quarters of a structural change. If your first-submission approval rate goes from, say, 60% to 85% after adding a risk advisor, that is the signal you need.
Yes, and for teams under ten people it is often the right first move. A fractional vCISO or risk consultant can own your risk register, run the quarterly board briefing and support vendor evaluations for a fraction of a full-time cost. The limit is continuity, because a fractional resource won't be in the room when unplanned decisions happen. Plan to convert it to a full-time role once the function proves its value.
I wrote this guide from my own work leading security programs. Product and category links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.