Security Governance With a Team of Five
How to run security governance with five people: a tiered control model, a short risk register, tiered vendor reviews and a one-page board report.
Loading...
How to run security governance with five people: a tiered control model, a short risk register, tiered vendor reviews and a one-page board report.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
With five people you can't govern everything, so you govern a few things completely and tell your board what you left out. For me that comes down to a short risk register the business owns, policies your platforms enforce for you, vendor reviews tiered by data access and a one-page board report each quarter. And one of the five should be a risk and compliance lead, even though that is the hire small teams skip most often.
See every Cybersecurity solution we list
The full Cybersecurity market, filtered by company size, deployment and NIST coverage.
Five people. That is your entire security team, and you still have a CISO title, a board that wants quarterly updates, a compliance calendar that never stops and attackers who don't care about your headcount. It is the normal situation for a lot of security programs outside big enterprises, and for some inside them after a round of budget cuts.
The instinct is to treat a small team as a temporary problem and tell yourself you will hire your way out of it next fiscal year. You won't. Headcount approvals take longer than you expect and onboarding takes longer than that, and nothing pauses while you wait. So the better move is to build a governance program designed for five people from the start, instead of a scaled-down version of what a 50-person team would do.
Governance is where small teams lose the most ground, more than detection or response. I mean the policies nobody reads, the risk register nobody updates and the vendor reviews that happen once and then drift. A five-person team that governs well will outperform a fifteen-person team that governs for show, and the rest of this guide is how to build that program.
The first mistake small teams make is scope creep in their own framework. They adopt the full NIST CSF or ISO 27001 control set, map every domain and then spend six months writing policies they will never enforce, so the framework ends up as a monument to good intentions.
What a five-person team needs is a tiered control model. Tier one is the controls that directly reduce your highest-probability, highest-impact risks, tier two is the controls you need for compliance, and tier three is everything else. You resource tier one first and tier two second, and you tell your board plainly that tier three exists but isn't funded.
That is risk-based prioritization, and a board should respect it. The conversation moves from "we cover everything" to "here are the ten controls we own completely, here is the evidence, and here is what we deprioritized and why." That is a far more credible position than a 200-control framework that is 40% implemented.
Team composition matters more than headcount. Five technical specialists will build great detection and weak governance, while a team with no technical depth will write good-looking policies that don't match what happens in the environment. You need balance, and the rule of thirds gives you a way to spread five roles:
The risk and compliance lead is the hire small teams skip most often, usually for another analyst. Without someone who owns governance as their main job, governance becomes everyone's side job, which means nobody owns it.
Most five-person teams keep a risk register because the auditor asks for one. It lives in a spreadsheet, gets updated before audits and has no link to how work is actually prioritized.
A register that works has three properties. It is short, with 15 to 25 risks at most, because 200 items is a list and not a register. Every risk has an owner outside security, since the business owns the risk and security advises on it. And every open risk maps to a funded control, an accepted risk with a written reason, or a budget request.
That third property changes your board conversations. Say your CFO asks why you need $200,000 for an identity governance product. You open the register and show the three risks it addresses, their likelihood and impact scores, and what a breach in that area would cost. Build the register that way from day one.
Five people can't enforce policy by hand, so every policy needs a technical control that enforces it automatically. If it doesn't have one, take it out of the library.
Run that check on your current policy set. For each policy, ask which technical control enforces it, and if the answer is "periodic manual review" or "employee training", the policy is aspirational. Your auditors will count it, but attackers won't.
The goal is to move enforcement into platforms: password policy in your identity provider, data classification in your DLP configuration, network segmentation in your firewall rules. Once the secure path is the default path, your people stop spending time on enforcement and spend it on exceptions and improvements instead.
Compare Cybersecurity solutions side by side
Features, integrations, NIST coverage and deployment for every Cybersecurity solution we list, in one table.
A mid-market company, meaning 100 to 999 employees, can have dozens of security-relevant vendors. Five people can't do a deep annual review on all of them, and trying to gives you shallow reviews of everything, which is worse than nothing because it creates false confidence.
Tier the reviews by data access and how critical the vendor is:
| Tier | Which vendors | Review |
|---|---|---|
| Tier 1 (4 to 6 vendors) | Handle sensitive data or have privileged access to your environment | Full annual review: SOC 2 Type II, penetration test results, incident history, contract security terms |
| Tier 2 (10 to 15 vendors) | Business-critical, lower data sensitivity | Light annual review: questionnaire, SOC 2 report, contract check |
| Tier 3 (everyone else) | All other vendors | Review at onboarding, then watch for breach notices |
Your risk and compliance lead runs the Tier 1 reviews personally, sends Tier 2 through a structured questionnaire, and automates Tier 3 monitoring with a third-party risk platform. That gives you coverage you can defend without burning your people on reviews that find nothing useful.
Your board doesn't want a 40-slide security update. They want to know whether things are getting better or worse, what the top risks are right now and whether you are spending the right amount.
So build a one-page report and keep the format the same every quarter, so the board can follow trends over time. It has four parts:
The metrics that land with boards are business ones. A board will care less about mean time to detect than about the share of critical systems with tested recovery plans, or the share of employees who finished security training in the last 12 months. A five-person team that explains itself clearly will get more budget than a twenty-person team that talks in jargon. For more on what to measure, see the security metrics your board cares about.
At five people, every manual process is a tax on the program, because each hour spent on work a machine could do is an hour not spent on governance, risk analysis or anything else that needs judgment.
Automate in this order. First alert triage and enrichment, so analysts stop pulling context by hand for every alert. Second, compliance evidence collection for SOC 2 or ISO 27001 audits. Third, access reviews, with provisioning and deprovisioning tied to your HR system, which replaces the quarterly access review your people dread and your auditors love but which rarely catches real risk.
The cost case is simple at this size. If a product saves each of your five people four hours a week, that is 20 hours a week, or about half a full-time role. If you assume a fully loaded cost of $150,000 per security hire, half a role is worth about $75,000 a year, so a $30,000 annual product pays for itself in about five months.
Controls drift, policies go stale and risk registers stop matching reality. That happens in every program, but faster in small ones because there is no redundancy. When your risk and compliance lead goes on leave, governance pauses, and when a technical operator leaves, what they knew leaves with them.
Put decay checks on the calendar:
Document everything as if your replacement starts tomorrow, including runbooks, the reasons behind decisions, vendor contacts and where the audit evidence lives. A five-person team that documents well survives turnover, and one that runs on what people remember doesn't.
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.
A five-person security team that governs well is a design choice you make on purpose. The teams that struggle at this size try to run a shrunken version of a large program. The ones that succeed build for the capacity they have: tiered controls, a risk register that drives budget, enforcement built into platforms and board reports in business language.
You won't cover everything, and you aren't supposed to. Cover the right things completely, be clear about what you deprioritized and why, and build a program that still holds up when someone is out or leaves.
Frame the hire around audit findings, compliance gaps and the quality of the risk register, and leave the job title out of it. Show the board the last audit report and the open findings that exist because nobody owns governance as their main job. A risk and compliance lead who closes three audit findings and keeps you clear of a regulatory penalty can pay for themselves in the first year.
Plan on 90 days for the foundation: a tiered control model, a risk register with business owners and a board report template. By six months you should have finished your first full vendor review cycle and cleaned up the policy library. By twelve months you should have a program you can defend to an auditor without weeks of preparation. Sequence it rather than doing everything at once.
Cut depth before breadth. Move Tier 2 vendor reviews from every year to every 18 months before you drop them, and defer policy updates in low-risk areas before you stop updating high-risk ones. Never cut the risk register or board reporting, because those protect your budget in the next cycle.
Make one person the compliance program owner, even if it isn't their only job, and buy automated evidence collection early. Manual evidence gathering for a SOC 2 Type II audit eats weeks of staff time. Automation takes most of that off your team, which is the difference between a manageable audit and two months under water.
Report business outcomes instead of framework scores. Rather than "we are at NIST CSF Tier 2", say "we can detect and contain a credential compromise in under four hours, and here is the test result that proves it." Boards understand outcomes, timelines and costs far better than maturity models.
Adopting a framework built for a 50-person team and then failing to implement it. You end up with a policy library nobody reads, a risk register that doesn't match reality and an audit that finds gaps everywhere. Start with a framework that fits the capacity you have, implement it completely and expand from there.
I wrote this guide from my own work running security programs. Product and category links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.