Fractional CISO & CTO
Security ownership and architecture judgment in one named person, at companies too regulated to go without either and too small to hire both full-time.
Every growing company builds its technology function in the same order, and most of them skip the same step. Somebody handy keeps the lights on. An MSP takes over laptops and helpdesk. Then, when the roadmap outgrows one person, they start hiring builders. The step in between - one person accountable for how all of it fits together and for whether any of it is defensible - never gets filled, because it is expensive and nothing is visibly on fire. Then a regulator writes, or a customer sends a questionnaire, or a test comes back.
That is the role I take. The argument for why it matters is set out in full in the technology stage most growing companies skip.
A security leader who can write the fix
Most fractional security leadership is advisory. You get someone who has held the title, runs good meetings, and produces a policy set. That is worth something, and it is not what breaks.
What breaks is specific and technical. Whether the vendor's demo matches the product. Whether the architecture survives the next order of magnitude. Whether a secret is sitting in a build pipeline where it should not be. Whether the recommendation in the penetration test report is even implementable against a load balancer that rotates its certificate every 90 days.
I came to security from engineering, not from compliance, and I still do the work. I can open the architecture, read the code, look at the cloud bill, and tell you what is actually wrong - then write the fix and produce documentation that holds up for a regulator. CISSP certified, Azure Solutions Architect, 20+ years running technology organizations, two exits.
What the role includes
The title covers a wide range in the market, so here is the specific version.
Regulated security obligations
FDA premarket cybersecurity and Section 524B submission content for connected devices and software-only products alike, HIPAA and PCI posture, penetration test programs, security questionnaires, and audit and diligence responses.
Application and product security
Authentication and authorization design, secrets in CI/CD pipelines, portal and API security, least privilege for developers, and the security of the repository itself. Most technology leaders cannot do this. It is the reason people call me.
MSP and vendor governance
Defining what your providers must achieve, reading their reports skeptically, verifying that tooling is deployed rather than merely purchased, and escalating when it is not.
Architecture ownership
One person accountable for the whole estate and how the pieces fit together. Not a diagram exercise: the running systems, the integrations between them, and the decisions that determine whether the next thing you build is cheap or expensive.
Cloud cost and posture
What is running, what is exposed, and what nobody can account for. Infrastructure accumulates quietly, and the security answer and the cost answer are usually the same answer: turn off what nothing is using.
Build, buy, and vendor selection
Whether the thing should exist, whether the demo matches the product, and whether the problem you are buying a solution for is the problem you actually have. This is where the largest amounts of money get saved or wasted.
Platform foundations
CI/CD, environments, observability, audit logging, and backups that have actually been restored from. The unglamorous layer that decides how fast everything after it moves.
Engineering team shape
What to hire and when, how to combine onshore and offshore, and how to keep contractors productive. Including the part where I tell you to hire somebody instead of paying me.
Board and executive reporting
Translating security and technical posture into the decisions and the money a board needs to act on, in language that survives contact with people who are not engineers.
This is not a managed service, and it is not a 24/7 monitoring operation. I do not want to image your laptops and you should not be paying me to. If what you need is a staffed security operations center or a helpdesk, that is a different purchase and I will say so.
What usually brings people here
Nobody wakes up wanting a fractional CISO. Something happens first. In order of how often I see it:
An FDA cybersecurity deficiency letter on a device or a software-only product, a security questionnaire, an audit finding, or diligence that needs answers your environment can actually support.
The report is thorough and the findings are real. The testing firm cannot remediate its own findings without losing its independence, and your team does not have the security context to translate a finding into a change.
You need somebody who can tell you what is actually wrong rather than what is politically convenient, and then go and fix it.
The MSP handles tickets, the developers ship features, and no single person can tell you how it all fits together, what it will cost to change, or where it is exposed.
Hiring is the most expensive way to discover you diagnosed the problem wrong. More builders rarely fixes a problem caused by the absence of an architect.
Somebody has to own the estate and defend the plan to the people writing the cheque, in terms they can act on.
How engagements are structured
Fractional security and technology leadership is a retainer. That is different from the fixed-price project work I also do, and the difference is deliberate: a project has a finish line, and holding a role does not.
A day or two a week is usually enough. That sounds too small to matter, and it is not, because the value is concentrated in a handful of moments - someone senior looking at what is about to be decided and saying there is a better way to do it. Which vendor. Which architecture. Whether to buy or build. Whether the MSP's compliance report says what everyone thinks it says. You still decide. You decide from a position of knowledge rather than ignorance, and over three years that difference compounds into either a platform or a rewrite.
What makes a retainer worth buying is that the responsibilities are named. A monthly fee for unspecified availability is how these engagements quietly turn into nothing. So every one starts by writing down which of the responsibilities above are mine, what arrives on what cadence, and what I am accountable for producing.
Terms are set per engagement. The right number of days depends on how much estate there is and how much is on fire, and I would rather scope it against your situation than publish a rate card that fits nobody. Tell me what is going on and I will come back with a shape and a price.
Two things hold regardless of the numbers. Everything I build, document, and configure is yours, and the engagement is designed so you can end it without losing the program. And when the work in one area grows past what a fractional owner should be doing, I will tell you to hire.
Versus the alternatives
Versus an MSP
An MSP delivers services. A fractional CISO decides what those services must achieve and verifies that they do. Different jobs, and they cannot be the same supplier, because the second one includes judging whether the first one is performing.
Versus a vCISO or vCIO from your MSP
Worth separating, because the labels get used interchangeably and what sits behind them does not. A vCIO is usually a service your managed provider sells you, delivered as a recurring advisory function. A fractional CISO or CTO is a named executive who joins your leadership team part-time and works for you.
It is an easy failure to walk into. A company decides it needs independent oversight of its managed provider, agrees with the principle, and then buys that oversight from the provider. The questions that would surface the provider's own gaps are never the ones asked. Nobody acts in bad faith. Oversight simply has to come from outside the thing being overseen. That argument is set out in why your MSP is not your security program.
Versus a full-time hire
The rule I use: hire full-time when there is enough work in one specialization to keep one person genuinely busy.
A regulated connected product needs a mobile engineer, a cloud and infrastructure person, a security specialist, and a portal developer across front and back end. Those are four different jobs. Early on none of them is a full-time load, and hiring four people to cover four part-time loads is how a company burns its runway. One senior person who can do all four costs less and moves faster.
The moment any one of them becomes a full week of work, hire for it. I will say so, and I would rather say it early than bill through it. Offshore capacity is genuinely useful, and one or two engineers in the US alongside it is worth what it costs.
Versus more developers
The most common substitution, and the most expensive. One company put real time and real money into an AI-powered search product that could not find what its users needed, because whoever chose it had no application background and there was nobody in the building whose field it was. The problem was never the search engine. It was tens of thousands of records whose meaningful content sat unstructured in free-text fields. Once that was named correctly the fix was quick.
Engineers execute decisions. They do not decide whether the thing being built should exist, whether the architecture survives the next order of magnitude, or whether the vendor's demo matches the vendor's product. Those decisions have a far larger blast radius than any individual sprint, and they are the ones companies currently make without help.
Why these engagements fail
Almost always the same reason: missing domain expertise.
Someone holding this role has to understand enough about security, infrastructure, cloud, and application development to be useful in all of them. The gap I see most often is application development. Someone arrives from a compliance, network, or people-management background, and then cannot help with the things that actually break: securing code repositories, protecting application secrets inside an automated CI/CD pipeline, or making sure developers work under least privilege.
The second failure is the role being handed to whoever is organized and available. It is not a reporting line you give the CFO or the COO. It is not a project manager who runs the vendor calls. And it is not a people manager - managing engineers and owning architecture are different jobs that companies conflate constantly.
When you are evaluating anyone for this role, including me, ask them to walk you through how a secret gets from a vault into a running container without ever existing in a repository. The answer tells you what you need to know in about two minutes.
Why me
I co-founded a SaaS conferencing platform, built PCI DSS-compliant billing from nothing, grew it to 10,000 customers and $9M in revenue, and sold it to NTT. I stayed six years, ascending to CTIO with 225 reports across eight countries and a $33M budget, the security function among them, reporting in turn to the board, the parent company board, and executive leadership.
After that I joined a healthcare workforce startup as employee number five, rebuilt the engineering organization to 40-plus, and helped lead the company to acquisition. Two exits.
Since then: a cybersecurity program carried through an FDA submission, a penetration test taken from report to a clean retest, a legacy Java EMR migrated to Azure, a digital banking platform migrated for 130,000 members, and the investigation and containment of a business email compromise.
If that background is not the shape of your problem, I will tell you in the first conversation rather than the third invoice.
Written on this
Start with a conversation
Tell me what is going wrong. If a fractional arrangement is the right answer I will scope it. If it is not, I will say what is.