InfoSec Made Easy
Building Your Security Team Series — Part 1
Start With Structure, Not Titles
How to build a security team that actually covers what matters — without an enterprise budget or a Fortune 500 headcount
You didn't wake up one morning and decide to build a security team from scratch. More likely, you were handed a problem. Maybe it came with a title — Security Manager, Director of Information Security, or some variation — and a set of expectations that significantly outpaced the resources available to meet them. Or maybe you've been carrying security responsibilities alongside everything else for so long that formalizing the function finally became unavoidable.
Either way, here you are. You have to build something real. And you have to do it with constraints that most security frameworks and leadership textbooks don't fully account for.
This post is for you. Not for the CISO of a 10,000-person enterprise with a $50 million security budget and a team of specialists. For the security leader in a midsize organization who's been told to build an enterprise-grade security function on a budget that would barely cover one senior engineer at a large tech company. For the manager who inherited "security" when it was just a folder in someone's Google Drive and a firewall nobody had reviewed in three years.
The first and most important thing we need to talk about — before tools, before headcount, before org charts — is structure. Specifically, why you need to start with structural thinking before you start making hiring decisions, building job descriptions, or drawing boxes on an org chart.
Recognize Where You're Starting From
Before you can build anything, you need to be honest about your current reality. Most security leaders in midsize organizations are starting from one of a few familiar places, and each one carries its own specific challenges.
Maybe you inherited security as "an IT function" — where the network administrator also handles firewall rules, the helpdesk team manages user accounts, and nobody has ever clearly owned incident response. Security has been happening, in the loosest sense of the word, but it's been fragmented, reactive, and entirely dependent on individuals who were never hired to do security work.
Maybe you're a team of one or two. You're covering everything — monitoring, policy, compliance, identity management, vendor reviews — and you're doing it by triaging aggressively and accepting that some things aren't going to get done. You know the gaps exist. You just don't have the bandwidth to close them all.
Maybe leadership has handed you an ambitious mandate — "build us a real security program" — with a budget that sounds meaningful until you start scoping what it actually needs to cover. You're being asked to deliver enterprise outcomes with midsize resources, and you're expected to do it without the luxury of specialists for every domain.
Or maybe the triggering event was simpler and more honest: risk is visibly growing — new regulations, a near-miss incident, a vendor breach in your industry — and leadership finally agrees that the informal security posture the organization has been operating on isn't sufficient anymore. Nobody is sure where to start, but they've pointed at you.
All of these starting points are valid, and all of them lead to the same first question: what does a security function at this scale actually need to look like? The answer isn't about titles or org charts. It starts with coverage.
The Reality of Midsize Security Teams
Let's ground this in numbers, because the context matters for everything that follows. Most midsize organizations — those operating in the $50 million to $1 billion revenue range — run security functions with somewhere between three and fifteen dedicated professionals. The average tends to cluster around six. That's not a large number when you consider the breadth of what a security function needs to cover.
A budget that's meaningful in absolute terms can still feel impossibly constrained when set against the full scope of security responsibilities. You're managing endpoints, cloud infrastructure, identity, compliance obligations, vendor risk, incident response capability, security awareness, and the ongoing work of keeping policies and controls current in a landscape that changes constantly. You can't hire a specialist for every one of those domains. Not at this scale.
This is the core constraint that shapes everything about how midsize security teams need to be built. You cannot specialize early. But you absolutely must cover the core domains. Those are not contradictory goals — but they require a fundamentally different approach than what larger organizations use. You need generalists who go deep in specific areas. You need roles designed around outcomes, not around narrow specializations. And above all, you need structural clarity about what needs to be covered before you write a single job description.
💡 Pro Tip
Before you write a single job description or ask for headcount approval, map your current coverage against each of the four pillars below. You need to know what's covered, what's uncovered, and what's covered so thinly that it represents a single point of failure. That map drives every structural decision that follows.
The Four Security Pillars You Cannot Ignore
Regardless of your organization's size, industry, or security maturity, there are four domains that every security function must cover. These aren't aspirational categories for when you have a bigger team. They're the irreducible minimum — the areas where an absence of coverage creates risk that cannot be managed or accepted away. It simply exists, unaddressed, until something forces it to the surface.
1. Security Operations (SecOps)
Security Operations covers detection, response, monitoring, and vulnerability management. This is the domain most people think of first when they think about security — the function that watches for threats, identifies when something has gone wrong, and coordinates the response when it does.
If this pillar is weak or absent, you won't know when you've been breached. That's not a hypothetical. Organizations get compromised and go weeks, months, or in some documented cases years without detecting the intrusion. Detection capability is what converts a security incident into something you can respond to. Without it, you're not managing risk — you're just hoping. Every other security investment you make is significantly less valuable if you can't detect when your controls have failed.
2. Governance, Risk and Compliance (GRC)
Governance, Risk, and Compliance covers the policies, frameworks, third-party risk management, audit readiness, and risk tracking that give structure to everything else the security function does. GRC is often the least exciting security domain to work in, and it's frequently underfunded as a result. That's a mistake that tends to surface at the worst possible moments.
If your GRC function is weak, leadership will be surprised by audit findings, regulatory gaps, and risk exposures that the security team knew about but never surfaced in a way that drove organizational decisions. Surprises at the executive or board level destroy trust in security leadership faster than almost anything else. GRC is how you prevent those surprises — and how you build the organizational credibility that lets the security function operate with appropriate authority and resources.
3. Identity and Access Management (IAM)
Identity and Access Management covers user provisioning and deprovisioning, multi-factor authentication, privileged access management, and the full lifecycle of how users get access to systems and data — and how that access is reviewed, adjusted, and removed as circumstances change.
This pillar deserves emphasis because it's consistently the most underinvested domain in midsize security programs, and it's consistently the domain that attackers exploit most successfully. The majority of significant breaches today don't start with zero-day exploits or sophisticated malware. They start with credential compromise — stolen passwords, phished accounts, over-provisioned access that gives attackers far more reach than the initial compromise should have allowed. Weak IAM turns a containable incident into a catastrophic one.
4. Security Architecture and Engineering
Security Architecture and Engineering covers cloud security controls, network segmentation, tool integration, and the foundational design decisions that determine how defensible your environment is from a structural standpoint. This is the domain that most directly determines whether the other three pillars have a solid foundation to operate on.
If your architecture is fragile — if systems aren't properly segmented, if cloud configurations are inconsistent or unreviewed, if your security tools are poorly integrated and creating blind spots — then everything else becomes harder and less effective. You can have excellent detection capability, strong GRC practices, and solid identity controls, and still be significantly exposed if the underlying architecture allows threats to move laterally through your environment unchecked.
How to Talk About Staffing to Leadership — and Why It Matters
Here's a practical scenario that plays out in organizations everywhere. A security manager identifies a critical coverage gap — maybe one person is responsible for identity governance, vulnerability remediation, and firewall rule management simultaneously — and goes to leadership to make the case for an additional hire.
The manager says: "We need to hire a security engineer."
What the executive hears: "You want to grow your team." This triggers budget scrutiny, headcount discussions, and the unspoken question of whether the existing team is being managed efficiently. The conversation becomes about the security function's growth appetite rather than about the risk the organization is carrying.
The same request, reframed: "Right now, identity governance, vulnerability remediation, and firewall rule management are all owned by a single individual. If that person is unavailable — for any reason — we lose operational control across three high-risk areas simultaneously. That's a concentration risk that creates real exposure for the business."
That's a fundamentally different conversation. It's not about the security team wanting more resources. It's about a specific, identifiable risk that the organization is currently accepting — probably without knowing it's accepting it — and what it would take to address it. Executives respond to risk framing in ways they don't respond to resource requests.
This reframing isn't manipulation. It's precision. The risk is real. The concentration is real. Your job is to describe it in terms that make the business implications clear to people who don't live inside the security function every day.
💡 Pro Tip
Map every critical security function to the person currently responsible for it, and identify anywhere that a single individual owns more than one high-risk area. Each of those overlaps is a single point of failure — and a potential business case. Present these to leadership as risk concentrations, not as staffing gaps, and the conversation changes completely.
Why Your Team Structure Should Be Flat — For Now
One of the most common mistakes security leaders make when building early-stage teams is over-investing in hierarchy. It feels like the right move. You're building something significant, and significant things have directors and senior directors and deputies. It looks like a real department on an org chart. It signals maturity and investment.
In practice, in a team of six or eight people, it's almost always the wrong call. Here's the simple reason: every manager you hire is one less person executing. In a small team, execution is everything. Your team's effectiveness is measured by what gets done — what gets monitored, what gets patched, what gets reviewed, what gets responded to. A manager who isn't also doing hands-on work is a resource cost that a small team can rarely afford without directly compromising coverage.
At this stage, you do not need directors, senior directors, a deputy CISO, or a layered management model. What you need is a structure in which everyone is operating, leaders function as player-coaches who are deeply engaged in execution while also providing direction, and organizational clarity comes from clearly owned responsibilities rather than reporting structures.
This isn't a permanent state. As your team grows and your program matures, appropriate levels of management will emerge naturally. But premature hierarchy in a small team creates bureaucracy without benefit — more coordination overhead, slower decision-making, and a coverage model that doesn't match your resource reality. Stay flat until growth genuinely requires something else.
Security maturity comes from coverage and clarity. Not from the sophistication of your org chart. The team that has clear ownership of every critical function, no single points of failure, and defined response procedures for its highest-priority scenarios is a more mature security organization than a team with impressive titles and an elaborate hierarchy that doesn't actually cover the basics.
How to Think About Allocating Your Team's Focus
If you have a small team covering all four pillars, how should you think about distributing their time and attention? There's no formula that works for every organization, but in typical midsize environments, effective allocation tends to look something like this:
- Detection and response (SecOps): approximately 30% — Monitoring, alert triage, incident response, vulnerability management, and threat intelligence. This is your highest-urgency domain and deserves the largest share of operational attention.
- Leadership and coordination: approximately 15% — Program management, cross-functional collaboration, executive communication, roadmap development, and team development. This is the overhead that keeps everything connected and moving.
- Governance and compliance: approximately 10–15% — Policy management, audit support, third-party risk reviews, regulatory tracking, and risk documentation. Underinvesting here doesn't feel urgent until it suddenly is.
- Cloud and application security: approximately 10% — Cloud configuration review, security design input on development projects, tool integration, and architecture-level security controls.
- Identity and access management: approximately 10% — Provisioning, deprovisioning, MFA enforcement, privileged access review, and access certification.
Look at that last number carefully. Ten percent on identity. That number is almost certainly too low for most organizations given how frequently identity is the initial attack vector. If you're building or rebuilding your security function, one of the most impactful decisions you can make is to consciously invest more in IAM than feels intuitive.
If you need to make the case for that investment to leadership, here's the framing that tends to land: "The majority of successful attacks we see in our industry begin with credential compromise — stolen passwords, phished accounts, compromised vendor access. Strengthening our identity controls directly reduces the probability of a successful breach, and it does it more effectively than expanding reactive monitoring after an attacker is already inside the environment." Executives fund likelihood reduction. Give them a clear picture of what IAM investment reduces, and the conversation changes.
Your First Goal Is Coverage, Not Perfection
This might be the most liberating thing in this entire post, so read it carefully: you are not trying to build a perfect security program. You are trying to build a program that covers what matters, at a level of quality that's sustainable with your current resources, with a clear path toward improving over time.
Perfection is a standard for organizations with unlimited resources and time — which is to say, it's not a real standard for anyone. Fortune 500 companies with 500-person security teams have gaps. Federal agencies with classified security programs have gaps. Your job is not to have no gaps. Your job is to know where your gaps are, manage the risk they represent, have a plan to close the ones that matter most, and communicate all of that honestly to the stakeholders who need to know.
For a midsize security team, the appropriate first-stage goals are: clear ownership of each of the four pillars, with named individuals responsible and accountable for each domain. No single points of failure — meaning no one person whose absence would create an unmanaged gap in a critical security function. Defined response procedures for your highest-priority scenarios, tested at least at a tabletop level. And basic risk visibility — a documented view of your top risks that leadership can understand and make informed decisions about.
If you can achieve those four things with your current team and resources, you have built something real. Not perfect. But real, functional, and defensible — to your leadership, to auditors, and to anyone who asks what your security program looks like. That foundation is what everything else gets built on.
📌 The Midsize Security Team Foundation Checklist
Before you move to hiring decisions, title structures, or tool purchases, make sure you can check off these four things:
- Clear ownership — Each of the four pillars has a named owner who knows they own it
- No single points of failure — No one person controls operational capability across multiple high-risk functions
- Defined response procedures — Your most critical scenarios (ransomware, data breach, insider threat) have a documented response plan
- Basic risk visibility — Leadership has a clear view of your top risks and has been given the opportunity to make informed decisions about them
What You're Actually Building
It's worth stepping back and being clear about what you're doing here, because the framing matters — for how you think about the work and for how you describe it to the people around you.
You are not building a department. Departments are organizational units defined by headcount, hierarchy, and budget authority. What you're building is something more important and more meaningful than that.
You're building a control system — a set of capabilities that gives the organization reliable visibility into its risks and reliable tools to manage them. You're building a risk management engine — a function that identifies what could hurt the business, communicates it clearly, and drives the decisions that reduce or accept that risk consciously. And you're building a trust relationship with leadership — one in which the people responsible for the organization's outcomes have confidence that security is being managed thoughtfully, honestly, and in alignment with business priorities.
Structure exists to support those three outcomes. Titles, org charts, and reporting lines are just the scaffolding. The outcomes are what matter. Start with the outcomes in mind, build the structure that enables them, and resist the temptation to let the scaffolding become the goal.
That orientation — structure in service of outcomes — is what separates security leaders who build programs that last from those who build organizations that look like security programs from the outside but don't actually function like them.
💭 Final Thought
When you're under-resourced and over-obligated, the instinct is to hire fast and fill seats. Resist it. The team you build without a structural plan will reflect the absence of that plan for years. Start with the four pillars. Map what you have against what they require. Build around coverage, not titles. Stay flat until growth demands otherwise. And keep your eye on what you're actually building — not a department, but a control system, a risk engine, and a trust relationship that the organization can rely on. Get that right, and everything else becomes possible.
About This Blog
Practical security leadership content for managers, aspiring CISOs, and infosec professionals who want to move up.
www.infosecmadeeasy.com
Comments
Post a Comment