InfoSec Made Easy
Building Your Security Team Series — Part 3 of 3
Hiring Order, Headcount Justification, and Career Path
How to grow your security team in the right sequence, make the business case for every hire, and build a place where good people want to stay
Building a security team isn't a single event. It's a sequence of decisions made over months and years, each one shaped by where you are, what your biggest gaps are, and what the business can realistically support at any given moment. Get the sequence right, and each hire builds on the last — compounding your capability and reducing your risk in a logical, defensible progression. Get it wrong, and you end up with a team whose structure reflects a series of reactive decisions rather than a coherent strategy.
That's what this post is about: the order in which you build, the language you use to justify each step, and the career infrastructure that keeps talented people engaged and growing once you've brought them in. Because hiring the right people is only half the problem. Keeping them — in a market where security talent is consistently in demand and your compensation ceiling may be below what large enterprises can offer — is the other half, and it requires just as much intentionality.
We've covered structure in Part 1 and the smart use of external partners in Part 2. This is where it all comes together: the practical, phase-by-phase guide to growing a security team that actually serves the organization's needs at each stage of its maturity.
📋 ABOUT THIS SERIES
This is the final post in a three-part series on building a midsize security team from the ground up.
- Part 1: Start With Structure, Not Titles
- Part 2: Smart Use of External Partners
- Part 3: Hiring Order, Headcount Justification, and Career Path (you're here)
Why Hiring Order Matters More Than You Think
Most security leaders, when they finally get budget approval to grow the team, approach hiring as a list of open positions to be filled. They write job descriptions for the roles they most obviously need, post them, and start interviewing. That approach isn't wrong, exactly — but it misses something important.
The order in which you hire shapes the culture, the capability, and the risk profile of your team for years. Hire your governance lead before you have basic detection in place, and you've built a well-documented program that can't see threats. Hire a security architect before you've stabilized your identity environment, and you're engineering elegant solutions on top of a foundation that attackers are still walking through the front door of. Hire a team of specialists before you have generalists who can cover the fundamentals, and you have a team with impressive depth in narrow areas and dangerous gaps in between.
The phased model below isn't arbitrary. It reflects a deliberate logic: stabilize before you mature, mature before you specialize. Each phase builds the foundation the next one requires. Skip a phase and you'll spend the next phase backfilling what should have been there from the start.
Phase 1: Stabilization (3–4 People)
The goal of Phase 1 is not sophistication. It is coverage. You need enough people in the right roles to ensure that the most critical security functions are operating — not perfectly, but consistently and reliably — before you start adding complexity.
A stabilized team at this phase typically includes four core roles. The Security Manager or CISO provides direction, owns executive relationships, manages the program, and makes sure the team is working on the right things. The Security Engineer handles the technical heavy lifting — tool configuration, integration, and the ongoing engineering work that keeps your security stack functional. The Security Analyst owns daily operations: monitoring, alert triage, vulnerability scanning, and the investigative work that turns raw detection data into actionable intelligence. And a Cloud/IAM hybrid covers two domains that are consistently underrepresented in early-stage security teams — cloud security controls and identity and access management. Combining these in one role is a practical compromise at this stage, not a permanent structure.
The outcomes this team needs to deliver before moving to Phase 2 are specific and non-negotiable: monitoring is in place and generating signal that someone is actually reviewing. Multi-factor authentication is deployed across all critical systems and user accounts, not just on paper but in verified practice. Vulnerability scanning is operational with a defined process for triaging and prioritizing what gets remediated. And incident response is documented — meaning there is a written plan, with named roles and defined procedures, that the team has walked through at least once in a tabletop exercise.
That last point deserves emphasis. An incident response plan that exists in a document but has never been practiced is significantly less valuable than one that has been stress-tested, even informally. You don't know what's missing from a plan until you try to execute it. Run the tabletop before you call Phase 1 complete.
The critical discipline of this phase is restraint: do not expand before you have stabilized. The temptation to move into Phase 2 hiring before Phase 1 outcomes are genuinely achieved is real — there's always another gap that feels urgent, always a capability that seems like it should come next. But expanding a team before the foundational work is done means your new hires will spend their early months navigating the same instability that's been slowing you down, rather than building on a solid base. Stabilize first. Then grow.
💡 Pro Tip
Before you declare Phase 1 complete and make a case for Phase 2 headcount, run a simple readiness check: Can you answer these four questions with documented evidence rather than general confidence? Is monitoring active and reviewed daily? Is MFA enforced on all privileged and remote access? Is vulnerability scanning running on a regular cadence with a triaging process? And has the IR plan been tested? If any answer requires a caveat, you're not done with Phase 1 yet.
Phase 2: Control Maturity (5–7 People)
Phase 2 is where your program starts moving from survival mode into something that looks like deliberate management. The foundational capabilities are in place. Now you're building the depth and ownership structure that takes your highest-risk domains from "covered at a basic level" to "actually well-managed."
The two additions that matter most at this stage are a dedicated IAM Engineer and a dedicated GRC Lead. Both of these roles address gaps that your Phase 1 team has been carrying as additional responsibilities — and both represent strategic risk that grows significantly as your organization scales.
A dedicated IAM Engineer is the hire that most midsize security leaders defer too long. Identity is consistently the domain where attackers find their easiest path — compromised credentials, over-provisioned accounts, stale access that was never cleaned up, privileged accounts without adequate monitoring. When these responsibilities are split across your Phase 1 team as secondary duties, they get the attention that's left over after everything else is handled. That's not enough attention for a domain this critical. A dedicated IAM engineer makes identity governance a primary responsibility rather than a shared afterthought, and the difference in program quality is significant.
A dedicated GRC Lead addresses a different but equally important gap. As your organization grows, the governance and compliance workload grows with it — more policies to maintain, more third-party vendors to review, more audit requests to manage, more regulatory requirements to track. When these responsibilities sit with your technical team members, they create the worst kind of context-switching: pulling engineers away from technical work to handle documentation and audit requests, or letting governance work pile up because there's no one whose primary job it is to own it.
When you make the case for these two hires, the framing that resonates with leadership is specific and measurable: "Right now, compliance reporting and identity lifecycle management are competing directly with incident response priorities for the same team members' time. When we're responding to an active incident, identity reviews slip. When audit season hits, detection work slows down. Dedicated ownership of these functions eliminates that competition, reduces our regulatory exposure, and lowers our breach likelihood by ensuring that identity governance gets the sustained attention it requires." That's a concrete, causal argument — not a request for growth, but a case for risk reduction.
Phase 3: Engineering Depth (8–12 People)
Phase 3 represents a meaningful shift in the nature of your security program. Phases 1 and 2 are largely about building the capability to detect, respond to, and manage risk. Phase 3 is about shifting the program's center of gravity from reactive to preventive — from finding and fixing problems after they emerge to reducing the rate at which they emerge in the first place.
The roles that drive this shift are a Security Architect, an Application Security Lead, and a Cloud Security Engineer. Each one addresses a category of risk that earlier phases have been managing reactively, and moves it toward proactive control.
A Security Architect brings the structural thinking your program needs to stop making the same categories of mistakes repeatedly. Architecture-level security decisions — how systems are segmented, how trust boundaries are defined, how new technology investments are evaluated from a security design standpoint — have long-term consequences that no amount of reactive security work can fully compensate for. A security architect makes those decisions deliberately rather than by default, and ensures that your security posture improves at the design stage rather than the remediation stage.
An Application Security Lead addresses one of the most significant and persistent sources of vulnerability in most organizations: the software they build or configure themselves. Applications developed without security input are consistently the source of vulnerabilities that your detection and response capability then has to manage. Embedding security into the development lifecycle — through code review, security testing, developer training, and design consultation — reduces the injection of new vulnerabilities at the source rather than trying to find and fix them after the fact.
A Cloud Security Engineer reflects the reality that most organizations' infrastructure has shifted significantly toward cloud environments, and cloud security requires specific expertise that generalist security engineers often don't have in depth. Cloud misconfigurations, inadequate identity and access controls in cloud environments, and gaps in cloud-native security tooling are among the most common sources of serious incidents at organizations that have moved rapidly to the cloud without equivalent security investment. A dedicated cloud security engineer closes that gap with the focus it requires.
The executive framing for Phase 3 investment is a shift in language from risk management to risk reduction: "We've built the detection and response capability to find and address threats when they appear. What Phase 3 does is reduce how many threats appear in the first place — by building security into our architecture and our development process rather than bolt it on afterward. Prevention is always less expensive than response, and this is the investment that moves us into prevention mode." Executives consistently respond to prevention language more readily than response language. Use it deliberately.
💡 Pro Tip
When making the Phase 3 case, quantify what reactive work is currently costing you. How many engineering hours per month go to remediating vulnerabilities that a security architecture review would have caught at design? How many incidents in the last year originated in application-layer weaknesses? Real numbers from your own environment are far more compelling than industry statistics, and they make the prevention argument concrete rather than theoretical.
How to Ask for Headcount Without Triggering Budget Resistance
Every security leader eventually faces the headcount conversation with leadership — and the outcome of that conversation depends enormously on how the request is framed. This isn't about manipulation or spin. It's about speaking the language that the people making budget decisions actually respond to.
The framing that consistently fails is the resource frame: "We are understaffed." That statement triggers a predictable internal response in every budget-conscious executive: Is this leader managing resources efficiently? Are they asking for growth because they genuinely need it, or because more headcount is always better from a manager's perspective? The request gets filtered through skepticism before the actual case is evaluated.
The framing that consistently works is the risk frame. You're not asking for more people — you're describing a specific, identifiable organizational risk that the current team structure creates, and proposing a solution. Consider these alternatives to the standard headcount request:
Instead of "we need another security analyst," try: "Our current structure creates a single point of failure across three critical control areas — detection, vulnerability management, and incident response ownership all sit with one individual. If that person is unavailable for any reason, our ability to detect and respond to threats degrades materially and measurably. Adding a second analyst eliminates that single point of failure."
Instead of "we need a dedicated IAM person," try: "Our mean time to remediate access-related findings currently exceeds our internal risk tolerance because identity lifecycle management is a secondary responsibility competing with incident response priorities. Dedicated ownership would bring our remediation timelines within acceptable bounds and directly reduce our exposure in the most common attack vector we face."
Notice what these framings have in common: they describe a specific risk, they make the business consequence concrete, and they connect the proposed hire directly to a measurable outcome. That's the structure of a headcount justification that gets approved — not because you've found magic words, but because you've made the business case clearly and honestly.
📌 The Headcount Justification Formula
Every headcount request should answer these three questions in plain language:
- What specific risk does the current gap create? Name it precisely — single point of failure, regulatory exposure, remediation timeline, coverage gap.
- What is the measurable business consequence? Increased detection time, breach likelihood, compliance exposure, operational dependency on one person.
- How does the proposed hire directly address that consequence? Connect the role to the outcome, not to the team's workload or capacity in the abstract.
Compensation Reality in Midsize Organizations
Let's talk about money — because it's a factor every midsize security leader has to navigate honestly, and avoiding the conversation doesn't make it easier.
The reality of security compensation in midsize organizations is that you will often be unable to match what large enterprises or well-funded technology companies can offer, particularly at the senior technical level. Security architects, cloud security engineers, and experienced incident responders command significant market rates, and those rates reflect a supply-demand imbalance that has persisted for years. A Fortune 500 company or a large tech firm can offer compensation packages — base salary, equity, bonus, and benefits — that most midsize organizations simply cannot match dollar for dollar.
Acknowledging this reality isn't defeatist. It's the starting point for a compensation and retention strategy that actually works. If you can't win on total compensation, you have to win on the things that total compensation can't buy — and there are real, meaningful things in that category that matter deeply to experienced security professionals.
Scope is one of them. In a large enterprise, a senior security engineer may spend their entire career in a narrow specialization, never touching the broader program. In a midsize organization, the same person might lead the design of the entire detection architecture, present findings to the executive team, and have direct input into the organization's security strategy. For professionals who want breadth and impact, that scope is genuinely compelling — and it's something only a smaller organization can offer.
Ownership is another. There's a meaningful difference between being one of forty security analysts in a large SOC and being the person who owns detection for an organization. The latter carries more responsibility and more visibility, and for the right professional, that ownership is worth something that doesn't show up on a compensation statement.
Access to leadership matters too. Security professionals in midsize organizations often have direct relationships with the CISO, the CTO, and in some cases the CEO that their counterparts in large enterprises never develop. For professionals who want to grow into leadership roles, that exposure has real career value.
None of this means compensation doesn't matter — it does, and you should pay as competitively as your budget allows. But it does mean that your value proposition as an employer is broader than your salary range, and you should be articulating that proposition explicitly and consistently in your hiring process and in your ongoing conversations with your team.
Building a Career Path That Keeps People
Attrition is one of the most expensive problems a security manager can face. The cost of losing a skilled team member — in recruiting time, onboarding investment, lost institutional knowledge, and the productivity gap while the role is filled — is significant. And in a field where demand for talent consistently outpaces supply, good people always have options. They will leave if they don't see a future where they're working.
The most effective retention tool available to a midsize security manager is a formalized, credible career progression framework. Not a vague promise that good work will be rewarded. An actual documented structure that tells every member of your team what skills and experience move them from where they are to where they want to go.
Junior professionals — your analysts and junior engineers — consistently want answers to the same questions. What specific skills and certifications will move them from analyst to senior analyst or engineer? What does the work of someone at the next level actually look like, and how do they start taking on that work to demonstrate readiness? What does the path from individual contributor to lead or manager look like, and what experiences does that path require?
Answering these questions clearly, in writing, and revisiting them in regular one-on-ones with each team member is one of the highest-leverage investments you can make in your team's stability. People who see a clear path forward are far less likely to go looking for one somewhere else. People who feel like their future at the organization is undefined tend to define it themselves — by leaving.
Career path clarity also has a secondary benefit: it forces you to think deliberately about how your team develops over time. A team whose individual members are all growing their skills and taking on increased responsibility is a team whose collective capability compounds year over year. That's the difference between a security function that gets incrementally stronger and one that stays roughly the same while the threats around it evolve.
The Annual Team Redesign Exercise
Here's a habit that separates security managers who build consistently improving programs from those whose teams gradually drift out of alignment with the organization's actual risk profile: once a year, step back and ask whether your team's structure still makes sense.
Not "are we doing good work?" — that's a different question. This question is structural: if you were building this team today, from scratch, with everything you now know about the organization's risk landscape and strategic direction, would you design it the same way?
Security teams drift. Responsibilities accumulate around individuals based on who was available when a need arose, not because they're the best structural fit. Tools get added without removing older ones that serve overlapping functions. The balance between reactive work and proactive work shifts based on what's been demanding attention, not based on what the risk profile actually calls for. Over time, a team that was well-designed when it was built can become misaligned in ways that aren't obvious day to day but are very visible in the aggregate.
The annual redesign exercise surfaces those misalignments before they become serious problems. Ask your team and yourself: Are any roles overloaded in ways that create burnout risk or quality gaps? Is identity governance getting the dedicated attention it requires, or has it been absorbed back into other responsibilities? Are we spending the right proportion of our time on detection and response versus prevention and architecture? Is there a single point of failure that's emerged as the team has evolved?
You don't have to act on every finding immediately — some will require budget or headcount that isn't available right now. But naming them, documenting them, and incorporating them into your security roadmap ensures they don't stay invisible until a resignation, an incident, or an audit finding forces them to the surface at the worst possible moment.
Bringing It All Together: What Security Maturity Actually Means
This series has covered a lot of ground — structure, outsourcing, hiring phases, headcount justification, compensation, and career development. It's worth stepping back and tying these threads together around the concept that runs through all of them: maturity.
Security maturity is not about looking big. It is not about the number of tools in your stack, the sophistication of your org chart, or the impressiveness of your framework alignment documentation. Maturity is functional. It's about whether your program actually does what it's supposed to do — consistently, reliably, and in a way that the organization can trust.
For a midsize security team, maturity shows up in three things above all. Clarity — every team member knows what they own, leadership knows what the security program covers and where the gaps are, and the organization has a clear-eyed view of its risk posture rather than a comfortable illusion of it. Coverage — the four pillars are addressed at a level that's appropriate for the organization's risk profile, with no single points of failure and no critical domains being managed as an afterthought. And credibility — the security function has earned the trust of leadership through consistent communication, honest reporting, and a track record of delivering on its commitments.
Those three things — clarity, coverage, credibility — are what you're building toward. Not a department. Not an org chart. A security program that the organization can genuinely rely on, that grows intelligently as the organization grows, and that communicates its value in language that earns the support it needs to keep improving.
Build that, and the titles and the org chart will take care of themselves.
💭 Final Thought
If you take one thing from this entire series, make it this: security maturity is not about looking big. It's about being functional, intentional, and honest. Cover the four pillars. Eliminate single points of failure. Use external partners strategically and govern them rigorously. Hire in the right order and make the case for each hire in risk language. Pay as competitively as you can and compete for talent on scope, ownership, and career clarity when you can't compete on total compensation. And every year, ask whether the team you have is still the team your risk profile requires. Do those things consistently, and you won't just build a security team — you'll build a security program that earns and keeps the organization's trust. That's the whole job.
Series Complete
Thanks for reading the full series. If this helped you, share it with a security manager who's building something real.
www.infosecmadeeasy.com
Comments
Post a Comment