A vCISO does not have a security problem. They have a memory problem.

The first time I ran security for more than one company at once, I assumed the hard part would be the security. It was not. The security was the part I already had. I had done the assessments, closed the findings, sat in the board meetings, argued the budgets. That knowledge walked in the door with me on day one, and it was portable across every client I took.

The hard part was walking into my third company of the day and remembering where we had left off.

That is the part nobody warns you about, and it is the part that decides whether a fractional practice works. A vCISO is not paid to know security. Every serious vCISO already knows security; it is the price of the seat. A vCISO is paid to hold continuity: to be the through-line for a program that has no full-time owner, across the weeks between check-ins and across every other client pulling at the same head. And continuity is not a security problem. It is a memory problem. The industry keeps trying to solve it with more expertise and more people, and it is neither.

The context-switch tax

Picture a Monday. Nine clients on the roster, four of them with something live this week. You open the first one. Before you can do a minute of real work you have to answer a question the program should be able to answer for you: where are we? So you open the shared drive, last month's meeting notes, the tracker somebody built in a spreadsheet, the Slack channel you were added to, and last quarter's board deck to remember what you told them. Fifteen or twenty minutes later you have reassembled the state in your head, and now you can start.

Then you switch to the second client and do it again. And the third. The expertise arrives in seconds; the state takes twenty minutes to rebuild, per client, every time you come back to it. That reassembly is unbilled, invisible, and once you are running more than a handful of programs it is a large fraction of the actual job.

The vCISO model is sold as leverage: senior judgment, fractionally, at companies that could never carry it full time. The unstated tax is that the judgment spends its first twenty minutes at every client remembering what it already decided. You are not paying a premium for someone to think. You are paying it to re-read.

Three places the memory leaks

The state does not live in one place, because there is no place built to hold it. So it leaks, and it leaks in three predictable directions.

Between sessions

A decision gets made in the monthly steering meeting. Defer the DLP rollout to Q3. Accept the finding on the legacy VPN until the migration lands. Move the SOC 2 window a quarter to the right. That decision lives in the meeting. Maybe in your notes, maybe in a follow-up email, maybe only in the memory of the four people who were on the call. It does not live in the program, because the program has no system that persists a decision and the reason behind it.

So next month you re-open half of it. Someone asks why the VPN finding is still there and nobody can say cleanly what was decided or why, so you re-litigate a call you already made. The program forgets between meetings, which means you have to be the thing that remembers. A program whose memory is a monthly meeting runs one day a month and drifts the other twenty-nine.

Between clients

Each client is its own island. Client A tracks findings in a spreadsheet. Client B lives in a Jira project. Client C bought a GRC tool during their last audit and abandoned it a month later. Client D's program is in your head and nowhere else. There is no shared layer underneath them, which means there is no such thing as “the way we run a program.” There are nine bespoke ways, one per client, and the only thing they have in common is you.

That is a quiet ceiling on the whole practice. A firm that cannot standardize how it holds state cannot standardize anything downstream of it. Not reporting, because every roll-up is hand-built. Not quality, because there is no baseline to hold a program to. Not onboarding, because a new consultant has to learn nine separate systems that happen to belong to the same firm. The practice does not have a methodology. It has you, repeated nine times, from memory.

Between people

The day the practice grows enough to hire, you find out where the state actually lived. You bring on an associate to take two clients off your plate, and the handoff is not a login and a folder. It is weeks of you narrating context that was never written down, because it was in your head. The associate builds their own version of it, slightly different from yours, and now the program exists in two heads that disagree at the edges.

Then the associate leaves, because associates leave. Their version of the program leaves with them, and you are back to reconstructing it from artifacts, for a client who has no idea any of this happened. Every engagement is a key-person dependency, and the key person is whoever last held the details. It is exactly the key-person risk you flag inside your clients' own programs, running quietly inside your own.

The Friday that costs you a weekend

It is Friday, 4:12 in the afternoon. An email comes in from one of your clients: “Auditor wants our access-review evidence Monday morning. Are we good?”

You are almost sure the answer is yes. But “almost sure” is not what you send a client the weekend before fieldwork. So you go find out. You open the shared drive. You open the tracker from six weeks ago. You find the Slack thread where the quarterly access review got reassigned after someone changed roles. You open last quarter's board deck to check what you told them the status was. Forty minutes later you have reconstructed a state the program should have known instantly, and you send a two-line reply that says, essentially, yes.

Those forty minutes were not judgment. They were archaeology. And you will do a version of it again for the next client, and the one after that, because the program cannot answer the question on its own. You are the only running instance of it that can. Most weeks the tax is quieter than a lost Friday. It is the twenty minutes before every call, the re-read before every reply, the “let me get back to you” that means “let me go find out what we already know.” But it is always there, and it scales with the number of programs you carry, not the number of hours you have.

Why hiring does not fix it

The instinct, when the reassembly tax starts eating your week, is to add people. Hire an analyst. Bring on a second consultant. Spread the clients out. It feels like leverage, and it is the move every growing practice makes.

It barely helps, because the constraint was never headcount. The constraint is that the state lives in people, and people are the wrong medium for state. Add a person and you have not added memory. You have added another place memory can hide, another handoff where it degrades, another eventual departure that can carry it out the door. The reconstruction problem does not divide across a bigger team. It multiplies.

You can feel the ceiling when you hit it. Two clients per consultant, maybe three if the programs are quiet. Past that, the tax of re-deriving state eats the margin the extra headcount was supposed to create. The practice stops scaling linearly with people, because every new person spends a fixed slice of their time reconstructing context the last person already reconstructed. The one thing you are actually selling, judgment, is the thing you have the least of to spare, and you are spending it on remembering.

Real leverage has to come from somewhere other than more heads. It has to come from the state living in a system instead of a skull: a place that holds last month's decision and the reason for it, the finding's current owner, the maturity score and the date it was set, the board narrative and what has changed since the last one. So that any consultant, walking into any client, is told where the program is, instead of being the only person who can work it out.

What a practice that remembers looks like

One operating layer, with every client a live program inside it. The decision from the steering meeting is captured where the work lives, so next month it is still there and nobody re-argues it. Findings carry owners and states that persist, so “are we good on access reviews” is a lookup and not an expedition. The board narrative assembles from the live program, so the quarterly deck is a review, not a weekend rebuild. And because every client runs on the same layer, a new consultant learns the practice once instead of nine times. And when someone rolls off, the program stays, because it was never in their head to begin with.

None of that is a security capability. It is a memory capability. The security you already have; it is why the clients hired you. What has been missing is a place to put the state so it stops living in you.

It is also where the between-meeting work goes: the finding that has not moved in three weeks, the evidence quietly going stale, the vendor renewal coming up that nobody is watching. That work rarely needs your judgment. It needs your attention, and attention is the single scarcest resource in a practice carrying a dozen programs. It is exactly the kind of work a system can hold and surface on its own, and increasingly the kind an analyst agent can drive between your check-ins, so your judgment shows up where it actually changes the outcome instead of being spent on remembering that the outcome needs attention.

The tell

Here is the test, and it takes ten seconds. Pick your most important client. Without opening a spreadsheet, a drive, or a Slack channel, answer four questions. What moved in their program last month? What is overdue right now? What is the next thing their board is going to ask about? Who owns the oldest open finding?

If you can answer cleanly, the program has a memory, and you should protect whatever is giving it one. If you reach for a file, or worse, for the associate who “has that one,” then the memory is you. And a program whose memory is a single person is one resignation, one lost laptop, one overbooked week away from not knowing where it is.

The vCISO business is sold as expertise for hire. What it actually runs on is continuity, and continuity is a systems problem the industry keeps trying to solve with more people and more spreadsheets. Judgment does not scale on memory you never wrote down. The practices that scale in the next few years will be the ones that stop asking their sharpest people to be the system of record, and hand them a system instead.

---

If you want the short diagnostic I use to find where a practice's program state actually lives, and where it leaks, reach out. We will send it.