The vCISO Trap: How the Industry Solved the Wrong Problem
The CISO exodus is real. Security leaders are declining roles, retreating to safer titles, and watching peers face personal liability for organisational failures they were never empowered to prevent. The post-Joe Sullivan era has made explicit what was always implicit: the CISO role, as commonly structured, is a liability trap dressed up as a leadership opportunity.¹
Prologue
The industry's response has been largely to reach for tooling. Better GRC platforms, more comprehensive audit trails, stronger evidence of due diligence. The logic being that if a CISO can demonstrate they identified the risk, escalated appropriately, and documented the decision, they are protected.
This logic is incomplete. Documentation does not restructure accountability. It just creates a more detailed record of the gap between what was recommended and what was resourced.
The more substantive response has been structural: the rise of the virtual CISO. Fractional security leadership, delivered by an external consultant who provides strategic direction without carrying the personal exposure of a full-time officer. The vCISO model has grown quickly, and for understandable reasons. For SMBs and scale-ups that cannot justify a full-time security hire, it offers access to senior expertise at a fraction of the cost. For security professionals, it offers the ability to do meaningful work without the liability profile of a named corporate officer.
There is, however, a problem with how most of the market has implemented this model. And it is the same problem Powell identified in the CISO role — just distributed across a portfolio of clients rather than concentrated in a single employer.
The Fractional Liability Trap
When a vCISO engagement is structured carelessly — and most are — it replicates the fundamental dynamics of the in-house CISO trap in fractional form.
Consider what typically happens. A consultant signs a services agreement, often with thin contractual language inherited from a general professional services template. They are engaged to "provide vCISO services," a phrase that is rarely defined with precision. They begin advising. They identify risks. They make recommendations. Some are implemented. Many are not — because implementation requires budget, prioritisation, and organisational will that the consultant does not control and cannot compel.
Months later, an incident occurs. The client's cyber insurer asks who was responsible for security. The client's board asks the same question. There is a contract that says a cybersecurity consultancy was providing vCISO services. There are emails and meeting notes that reference risks identified and recommendations made. There is no clear record of which recommendations were declined, by whom, and on what basis. There is no documented acknowledgment that the client accepted specific risks. There is no formal record of what the client's environment looked like at the time the advice was given, or how it changed during the engagement.
In this scenario, the vCISO has not escaped the liability trap. They have simply moved from being an employee who might have employment law protections to being an external contractor with a professional liability policy and a contract that was never designed to carry the weight now being placed on it.
The tooling-first response to this problem — better documentation, more comprehensive reporting — does not fundamentally change the dynamic. What changes the dynamic is structuring the engagement correctly from the outset.
What Structural Protection Actually Requires
A properly structured vCISO engagement must address four distinct liability vectors, each corresponding to a failure mode in the typical market implementation.
The pre-existing condition problem
When a consultant begins an engagement, they inherit an unknown quantity of undisclosed risk. Legacy vulnerabilities, unresolved audit findings, prior incidents that were never properly remediated, and technical debt that nobody wanted to mention during the sales process. Without a formal pre-engagement disclosure mechanism — a documented process by which the client warrants that all material known security issues have been disclosed — the consultant has no clear basis for separating their liability from the client's accumulated history. Anything that goes wrong can be attributed to the engagement period, regardless of when the underlying condition originated.
The recommendation rejection problem
Security consultants make recommendations. Clients deprioritise them. This happens constantly and for entirely legitimate reasons — budget cycles, competing priorities, risk appetite. The problem is not that clients decline recommendations; it is that this decision is rarely documented in a way that creates clear accountability. A verbal "we'll get to it next quarter" in a steering committee meeting does not constitute documented risk acceptance. Without a formal mechanism for recording declined recommendations, assigning ownership, and obtaining explicit client acknowledgment, the consultant retains residual exposure for incidents arising from unimplemented advice.
The moving target problem
An engagement begins with a defined scope and a known environment. Over time, that environment changes. New cloud infrastructure is deployed. A SaaS vendor is onboarded. An acquisition expands the attack surface. Development teams adopt tools that no one in security is aware of. The consultant continues advising based on the environment as they understand it, which may bear limited resemblance to the environment as it actually exists. Without a formal obligation for clients to notify the consultant of material changes — and a corresponding liability limitation for changes that were not disclosed — the consultant's exposure continues to expand as the client's environment evolves, regardless of whether the client was informed of the changes.
The scope ambiguity problem
The distinction between strategic advisory services and operational security management is one of the most consequential in the vCISO model, and one of the least clearly drawn in typical contracts. An advisor who provides guidance is in a fundamentally different accountability position than an operator who manages infrastructure. The former shapes decisions; the latter owns outcomes. When a contract uses imprecise language — "provide vCISO services," "oversee security programme," "support compliance initiatives" — it creates ambiguity about which of these roles the consultant actually occupies. In a dispute, that ambiguity will be resolved against the consultant.
The Cybersecurity Programme as a Missing Link
Beyond contractual protections, there is an operational gap in most vCISO engagements that receives insufficient attention: the absence of a formally approved, client-owned cybersecurity programme.
A programme document — a living roadmap of prioritised security initiatives, approved by a named client stakeholder, reviewed and updated quarterly — does something that a risk register alone does not. It creates a shared, signed record of what the client has committed to doing, what they have explicitly decided not to do in the current period, and who owns each decision. The deferral log within that programme is particularly significant: it captures every recommendation raised but not included in the current programme cycle, along with the rationale and the name of the stakeholder who approved the deferral.
This is the missing link between informal email recommendations and formal risk register entries. The risk register captures major risks. The programme and its deferral log capture everything else — the medium-severity findings, the deferred patches, the security awareness training that keeps getting pushed to next quarter. These are precisely the items most likely to be the proximate cause of an incident, and the ones for which accountability is most contested when something goes wrong.
A consultant who has obtained a quarterly sign-off on a programme document, including explicit acknowledgment of deferred items, has a materially different liability position than one who sends reports into an organisational void and hopes that recommendations are acted upon.
What a Properly Structured vCISO Engagement Looks Like
The following is not an exhaustive checklist. It is the minimum structural foundation for an engagement that does not replicate the problems it was designed to solve.
At engagement commencement:
A formal pre-engagement disclosure questionnaire, signed by an authorised client representative, warranting that all material known security incidents, vulnerabilities, audit findings, and technical debt have been disclosed. The consultant's liability is explicitly limited to matters arising after the engagement start date and within the disclosed environment.
A Service Agreement that clearly delineates advisory versus operational responsibilities, with explicit language stating that implementation decisions and operational security management remain with the client.
A cybersecurity programme, approved by a named client stakeholder, establishing the agreed scope of work for the engagement period.
During the engagement:
A formal process for documenting declined recommendations, whether through the programme's deferral log, the risk register, or a dedicated written acknowledgment. The threshold for formal documentation should be lower than most consultants currently apply — not just major risks, but any recommendation that is explicitly deprioritised.
A contractual obligation for the client to notify the consultant of material environment changes within a defined timeframe, with a corresponding liability limitation for changes that are not disclosed.
Quarterly environment review sign-offs, at which the client confirms in writing that the environment remains as previously disclosed or documents material changes that have occurred.
In the contract itself:
An explicit advisory-versus-operational distinction that is reinforced in the execution clauses, not just buried in the terms and conditions.
A liability cap that reflects the advisory nature of the engagement and is calibrated to the fees paid rather than the value of the assets being protected.
A claims period provision that distinguishes between invoice disputes, visible service delivery complaints, and latent security defects — each with an appropriate notification window.
Governing law and jurisdiction that reflects the consultant's home territory, not the client's preference.
The Harder Problem
None of the above is technically complicated. The structural protections required to make the vCISO model genuinely different from the in-house CISO trap are well understood. Contracts can be drafted. Processes can be implemented. Quarterly reviews can be scheduled.
The harder problem is cultural. The vCISO market has grown rapidly and, in many cases, informally. Consultants who moved from employment to fractional work often brought their employment-era habits with them — doing the work, making recommendations, attending the meetings — without rebuilding the engagement framework from first principles. Clients, for their part, often engage vCISOs precisely because they want the expertise without the governance overhead of a properly structured security function. The path of least resistance is an informal arrangement that serves the immediate commercial interests of both parties while leaving the liability question unresolved.
That works until it doesn't. And when it doesn't, it will not matter whether the consultant was fractional or full-time, external or internal. What will matter is whether the engagement was structured to distinguish the consultant's accountability from the organisation's.
The vCISO model is a genuine structural innovation in how security leadership is delivered. The CISO exodus is real, and the model's appeal — for both practitioners and the organisations they serve — is legitimate. But the innovation is in the delivery model, not in the liability architecture. Getting the latter right is not optional. It is what determines whether the model actually solves the problem it claims to address.
References
¹ Jeremy Powell, The CISO Exodus: When the Weight Becomes Too Much, LinkedIn Pulse, 2025. https://www.linkedin.com/pulse/ciso-exodus-when-weight-becomes-too-much-jeremy-powell-10tle/
