Virtual CISO Services: How an MSP Launches a vCISO Practice

Want the testing arm of your vCISO practice delivered under your own brand?
Get a Pentest Quote
Launching a vCISO Practice title card with a lock icon in the MSP Pentesting brand style.

Most MSPs launch virtual CISO services by naming one senior engineer the vCISO and putting a line on the rate card. Six months later that engineer is buried in evidence requests, two clients are annoyed, and nobody can say what the practice actually sells. MSP Pentesting is channel-only, so we sit underneath a lot of these practices as the testing arm, and we get a front-row seat to which ones survive year two.

The ones that survive got three things right before the first client.

A staffing model with more than one person in it. A first ninety days that produces artifacts on a calendar. And an honest answer for the moment a client asks who's going to check the work.

This is the build guide. If you're still deciding what to call it, we covered the naming question in fractional CISO services versus vCISO, and the retainer math lives in our piece on vCISO pricing. Neither of those is repeated here.

The staffing model, honestly

A vCISO practice that's one talented person is a consultancy with a marketing problem. It caps at that person's calendar, it dies when they take a vacation, and the client is buying a human rather than a service. Which is fine, but it isn't a practice.

Four roles have to exist. They don't have to be four people.

The advisor whose name is on it

Somebody has to sit in the board meeting, the insurer's call and the auditor's kickoff and answer without hedging. That person needs to be able to read a SOC 2 report, argue with a security questionnaire, and say no to a client's CFO. Certifications help you get in the door and they don't do this job. Having survived an audit does.

One advisor can hold the relationships. They cannot also do the paperwork, which is the mistake everyone makes.

The analyst who makes it profitable

Evidence collection, control mapping, policy drafting, ticket chasing, screenshotting configurations, updating the risk register. This is the majority of the hours in any real engagement and it's the work that destroys margin when a senior advisor does it.

Hire or assign this role before your second client, not after your fifth. If your advisor is still exporting user lists at month four, your practice is already unprofitable and you just can't see it yet.

The library that makes it repeatable

Not a person. A shelf. A policy set you own, a control-mapping spreadsheet, a risk register template, a board deck skeleton, a standard questionnaire answer bank, and an onboarding checklist. Build it during client one, harden it during client two, and by client three you're delivering a method instead of improvising.

Ninety percent of what a vCISO produces is the same across clients. Treating that as bespoke work is the single biggest margin leak in the category.

The tester you don't employ

Covered below, and it's the role most practices bolt on far too late.

RoleWhat it carriesWhat breaks without it
The named advisorJudgment, relationships, the roomNobody can answer the board, so the client hedges
The delivery analystEvidence, mapping, policy draftingSenior hours do junior work and margin vanishes
The reusable libraryTemplates, control map, deck skeletonEvery client is bespoke and you never scale
The independent testerProof the controls workYou are grading your own homework on the questionnaire
Build it or buy it, a two column checklist for a new vCISO practice. The left column lists what to own: the named advisor, your policy and control library, the client roadmap, the risk register, and the leadership meeting. The right column lists what to partner for: penetration testing, deep cloud engineering, an incident response retainer, legal and privacy counsel, and the audit opinion itself.

The left column is what you have to own, because it's where your judgment and your client relationship live. The right column is where buying beats building for almost everybody, and where trying to build it anyway is what stalls a practice in year one.

The first ninety days of a client engagement

If you can't describe the first quarter as dated deliverables, you're selling hours and the client will eventually notice. Here's the shape that works, and it's deliberately front-loaded because the client's confidence in you is decided in the first six weeks.

Days 1 to 15, get oriented and get access

Kickoff with whoever signs things, not just IT. Establish the forcing function in writing, because that's what the whole engagement gets measured against. A SOC 2 date, an insurance renewal, an enterprise customer's vendor review, a board that got scared. Then get read access to the tenant, the ticketing system, the HR onboarding process and last year's insurance application. That application is the single most useful document nobody thinks to ask for. It tells you exactly what the client already promised somebody.

Days 16 to 45, assess against a named framework

Pick one framework and say which. CIS Controls v8 if there's no compliance driver and you want something an owner can follow. The NIST Cybersecurity Framework if the board wants functions and tiers. The actual audit framework if there's a date. Do not invent your own scoring model. An auditor, an insurer and the next provider all need to read this, and a homemade maturity scale reads as marketing.

Interview the people, don't just scan the tenant. Half of what you'll find is process, not configuration.

Days 46 to 75, turn findings into a funded plan

A gap list isn't a deliverable. A roadmap with owners, dates and rough costs is. Sequence it so the first quarter contains at least two things that are cheap, visible and finishable, because you need a win before you ask for real budget. Put the expensive items in quarters three and four with the reason they're expensive written next to them.

This is also where the risk register gets born, in the client's language, in their words, about their business.

Days 76 to 90, present and set the cadence

Present to leadership, not to IT. Get the roadmap approved or amended in the room. Then set the standing meeting, monthly or quarterly, where those same three documents get updated in front of the people who fund them.

That meeting is the product. Everything else is preparation for it.

Five step flow for the first ninety days of a vCISO engagement: kickoff and get access, assess one named framework, cost the roadmap, present to leadership, then set the meeting cadence.

Where the work actually comes from

Nobody searches for a vCISO. They search for the thing that scared them. So stop marketing the service and start attaching it to forcing functions you can already see.

  1. Your own base. You already know which clients just signed an enterprise customer, just got a questionnaire, or just renewed cyber insurance with new warranties. That's your pipeline and it's sitting in your PSA right now.
  2. Insurance brokers. Brokers watch clients fail applications every week and have nowhere to send them. One broker relationship out-produces a quarter of content marketing, and the referral arrives pre-motivated with a deadline.
  3. Audit firms and accountants. A CPA firm doing readiness work can't also own the client's program without independence problems. They need somebody to hand it to.
  4. Private equity sponsors. A sponsor with ten portfolio companies wants consistent security reporting and won't fund ten security leaders. This is the highest-leverage motion in the whole category and almost nobody works it.
  5. The post-incident window. After a real incident the board asks who owns this. If nobody can answer, they'll buy an answer inside the quarter. Be the firm that already has a proposal shape ready.

Notice what isn't on that list. Cold outbound to companies with no forcing function. Those deals take a year and close at a discount.

The handoff you can't skip

Here's the structural problem that decides whether your practice is credible.

Your vCISO picks the framework, designs the control set, chooses the vendors, writes the policies and approves the exceptions. Then somebody outside asks for proof those controls work. An insurer, a SOC 2 auditor, an enterprise procurement team, a PCI QSA.

You can't grade your own homework.

This isn't a philosophical point. PCI DSS v4.0.1 asks for testers with organizational independence from the environment under test. Insurance applications and vendor questionnaires ask whether an independent third party tested in the last twelve months. And if your own vCISO wrote the policy that your own engineer implemented and your own tester signed off on, the client's biggest customer is going to notice on the questionnaire.

So separate it from day one. The vCISO owns the program. Somebody else tests it. Most of our partners run that as white-labeled penetration testing under their own brand, which keeps the independence real without handing the client relationship to a competitor. If you'd rather understand the commercial shape of that arrangement first, our pentest partner program lays out how the reporting and the margin work.

Say it to the client before they ask. It sounds like confidence when you raise it and it sounds like a dodge when they do.

Packaging without overpromising

Two packaging mistakes kill practices. Selling hours, and selling everything.

Selling hours means every month becomes a negotiation about whether you did enough. Sell named deliverables and a meeting cadence instead, and let the hours land where they land.

Selling everything means the retainer quietly absorbs the penetration test, the remediation labor, the tooling and the audit support, and by month five you're doing project work at advisory prices. Keep testing, remediation engineering and audit-week support outside the retainer as scoped work. Everyone is happier, including the client, who gets a bill they can trace to a thing.

And whatever you call it, ciso as a service, vCISO services or a security program retainer, make sure the proposal says what the client gets in ninety days. That sentence closes more deals than the title does.

What MSPs ask before they stand the practice up

How many people do you need to launch a vCISO practice?

Two, plus a testing partner you don't employ. One advisor who can sit in front of leadership and one analyst who can carry the evidence work. Launching with one person works right up until the second client, which is exactly when you're least able to fix it.

What should the first client engagement produce?

A current-state assessment against a named framework, a costed roadmap with owners and dates, a risk register leadership will actually read, and a standing meeting. Four things. If your proposal lists twenty, you're describing a year, not a quarter.

Do we need our own GRC platform?

Not to start. A platform speeds up evidence collection and it'll happily produce a beautiful report that means nothing. Buy it once you have enough clients that the licensing is cheaper than the analyst hours, and never let it decide your methodology.

Can our vCISO run the client's penetration test?

They can run the scoping conversation and they should. They shouldn't perform or sign the test on a program they designed. That's the independence line, and auditors, insurers and enterprise buyers all check it.

How do you know a client is ready for virtual CISO services?

There's a date on something. An audit, a renewal, a vendor review, a board request. Without a forcing function you're selling insurance to somebody who's never seen rain, and those deals stall in procurement.

Build the machine, then hire the tester

Virtual CISO services aren't a title you assign, they're a delivery machine you build. Two roles minimum, a library you keep sharpening, a ninety-day plan you can put on a calendar, a pipeline attached to forcing functions instead of ad spend, and a tester who doesn't work for you.

Get that last part wrong and everything above it becomes an opinion.

Send us the roadmap you're already selling and get a pentest quote. We'll cost the testing line before one of your advisors promises a client a date for it.

Author

Connor Cady

Founder

Connor founded MSP Pentesting after working in the pentest industry and seeing a massive gap in the market. MSPs were being forced to choose between overpriced corporate firms and shady, automated scanners that auditors hate. He built this company to solve that "sticker shock" and give the channel a partner that prioritizes their margins and client relationships.

Join our MSP Partner Program

Want reseller pricing, sample reports, and partner resources?
Book a call with our team to get access.