Most MSP security practices are one resignation away from a hard quarter. If every security answer in your shop routes through the same person, the thing at risk goes well beyond the seat you would need to backfill. It is the working context that makes the service deliverable: which client environments have which quirks, why each risk decision was made, what was promised in the last QBR, and what the auditor said in March. When that person leaves, the checklist stays behind, and the context goes with them.
This is a different problem from the one your continuity documents cover, and you can treat it the way you treat any other business risk: put a number on it, then fix it on your own schedule instead of during someone’s notice period. This article does both.
Why a Business Continuity Plan Doesn’t Cover Practice Continuity
If a client asked you tomorrow how they would survive losing a key employee, you would have an answer ready. You have probably built them a business continuity plan template that covers exactly that scenario. The harder question is the mirror image: what happens to your security practice, and to the recurring revenue attached to it, if your one security person hands in their notice on Friday?
Those are two different jobs. The client’s plan protects their operations from disruption. Practice continuity protects the security revenue you built on one person’s expertise. Most MSPs have the first in a template library and the second in the back of their mind, often filed under things to worry about later, and later has a habit of arriving unannounced.
How Key-Person Risk Builds in an MSP Security Practice
Nobody designs a single point of failure on purpose. It happens because the economics push you there. Security talent is scarce and expensive: the global workforce gap sits at 4.7 million unfilled cybersecurity positions, and MSPs feel that scarcity directly every time they try to hire for a security role. So you hire one strong security lead, build the vCISO offering around them, and grow. Every new client deepens the dependency, because every engagement adds context that lives only in that person’s head.
Hiring a second senior as insurance rarely survives contact with the payroll math. A practice billing a few thousand dollars a month in security services cannot carry two six-figure specialists, one of them mostly redundant. That is why the practical answers involve restructuring how the work is delivered without hiring more staff, and why pretending the dependency does not exist remains the most popular strategy by default.
What makes this a planning question rather than a philosophical one is how often security people move. Average CISO tenure runs 18 to 26 months, a fraction of the tenure of other executives, and in recent IANS Research survey data, nearly 70% of security leaders said they were open to changing jobs within the year. Your security lead does not have to be unhappy for the risk to be real. They can be poached, they can burn out, or they can simply want a vacation longer than the practice can survive.
What You Lose When Your Security Expert Leaves
The visible cost of a departure is replacement, and it is well studied: filling a role typically costs somewhere between one half and two times the annual salary once recruiting, ramp time, and lost productivity are counted. For a senior security hire in a market with a multi-million-person shortage, expect the high end of that range, with a search measured in months rather than weeks.
The invisible cost is the one that damages a security practice, because what leaves is client-specific context of the kind no job posting can ask for:
- Posture history. Where each client started, what has improved, and which findings keep coming back.
- Decision rationale. Why the client’s backup exception was accepted, why the multifactor authentication rollout was staged the way it was, what tradeoff was agreed and with whom.
- Relationship trust. The client bought security from a person. When the person goes, the client quietly re-evaluates whether they bought it from your company at all.
- Delivery shortcuts. The undocumented knowledge of which assessment questions matter for this client and which sections of the report the CFO actually reads.
The standard prescription for all of this is documentation and cross-training, and the standard prescription is not wrong so much as incomplete. Documentation programs fail in well-known ways: documents get written once and never tested against a second person actually performing the task, nobody owns the review cycle, and the pages capture what was done but not why. Cross-training fails the same way, with backup owners assigned on paper who never run a real engagement. The deeper issue for a security practice is decay. Client context changes with every assessment cycle, so even good documentation is a depreciating asset. It buys you time in a handover, not a way to hold the practice together.
How to Calculate Your Practice’s Bus Factor
Software teams have a blunt name for measuring this kind of exposure. The bus factor is the minimum number of people who would have to disappear before a project stalls, and a bus factor of one is a single point of failure. The concept translates cleanly to a security practice, and unlike most risk language, you can compute it in an afternoon.
Walk your client list one at a time and answer four questions honestly for each:
| Question for each client | What a bad answer looks like |
|---|---|
| Who besides your security lead could run this client’s next assessment to the same standard? | Nobody, or a name you are not confident about |
| Could anyone else explain the client’s last three risk decisions, and the reasoning behind them? | The reasoning exists only in one person’s memory |
| Where does this client’s security state live? | Spreadsheets and inboxes owned by one person |
| How long would a real handover take, assuming the leaver cooperates? | You genuinely do not know |
Count the clients where the honest answer to the first question is nobody. Say you run 12 security clients and the count comes back nine: that is nine clients’ worth of monthly security revenue that stalls if one person leaves, and it is the number to put in front of yourself each quarter. If this is your first time running the exercise, expect the answer to be most of the list, which is uncomfortable and also the point. A number you can calculate is a number you can improve, and it gives you something concrete to revisit each quarter instead of a vague unease.
The fourth question deserves particular honesty. A cooperative handover of a single complex client can consume days of senior time. Multiply by your client count and compare it against a standard notice period, and the arithmetic typically settles it: two weeks of notice will not carry a full client book across.
How to Reduce Key-Person Risk Without a Second Senior Hire
Improving the number is structural work, and the structure matters more than the effort. Practices that survive departures share a few habits, and none of them is heroic documentation:
- The methodology belongs to the practice. Assessments, policy work, and roadmaps follow one standard process for every client, so the way work gets done is not a personal style that leaves with its author. The same standardization is what lets delivery scale without the senior in every engagement, which means continuity work doubles as growth work you can justify this quarter.
- Client state lives in a system of record. Posture, findings, tasks, and decisions sit somewhere any authorized person can read, with the current status visible rather than reconstructed from emails.
- Decision rationale is captured as part of delivery. Not as an extra documentation chore, but as a field filled in when the decision is made. The why is the part of context that hurts most to lose and costs least to record at the moment it happens.
- Someone else touches every client. A second person runs at least part of each engagement during the year. Real coverage comes from having done the work, and a vacation is a cheap, low-stakes way to test whether the handover actually holds.
What changes is not the value of your senior person but what that value is attached to: judgment, client relationships, and the hard calls, rather than being the only place the practice’s memory lives.
Security Expertise That Survives Turnover
The structural fixes above share a premise: the expertise your clients buy has to live somewhere more durable than one person’s head. This is where platform choice becomes a continuity decision and not just an efficiency one. When the assessment logic, the prioritization, and each client’s full security state are embedded in the delivery platform itself, a departure becomes a transition rather than a crisis. The next person opens the same client record, sees the same posture history and the same reasoning, and continues the same roadmap.
Partners describe the effect in exactly these terms. ECI’s security team found the platform let them take people who are not as senior and have them deliver the same level of service as someone with 10 years of experience, because the methodology guiding the work is built in rather than remembered. That is typically framed as a scaling benefit, but it is equally a succession plan.
Cynomi’s Security Growth Platform carries your methodology and every client’s security state in one place, so your practice’s memory survives any single departure. Run the bus-factor walk on your own client list this week. If the number that comes back is one, you now know precisely what to fix, and you get to fix it before anyone hands in a letter.
Table of contents
