Virtual CISO · Remediation roadmap
Every gap becomes a task with an owner, a date and the evidence it is done
A gap analysis that ends in a report has moved the problem rather than solved it. What comes out of ours is a worked plan: each finding turned into a task somebody can pick up and do, sequenced against what your organization can actually absorb in a quarter, and followed until the proof is attached to it.
A task is a method, not a line on a to-do list
“Implement access control” is a finding, not an instruction. It tells the person who has to act what they failed at rather than what to do about it, which is how action plans end up untouched for a quarter and then rewritten. Every task here opens with what the control is for and then sets out a numbered procedure for putting it in place — written to be handed over, rather than interpreted.
Under the general steps sits the part that cannot be generated: a note from your vCISO about your environment. Which of your systems it applies to, what you already have that partly covers it, what was agreed in the workshop, and what happens next. That note is the difference between a method and a template with your logo on it.
- What the control is for, before anything about what to do
- A numbered procedure, so nobody has to translate a framework clause into work
- A priority from critical to low, and an estimate of the effort involved
- A note from your vCISO wherever the general steps need changing for your environment
Part of it is ours, and part of it never will be
The governance half is ours and does not come back to you as homework: the policies, the procedures, the registers behind them, the evidence store, the preparation for audit. Anything that alters a running system is not, because that change has to be made by somebody holding credentials for it — and we deliberately hold none.
The line falls task by task, and it is drawn before the month starts rather than discovered halfway through it. Where the work belongs to an external IT provider, they can run it from a ticket in their own service desk, with that ticket linked to the task here, so being part of the plan does not oblige them to live in somebody else’s portal. Seven of the service desks your provider is most likely to run connect out of the box and work in both directions; anything else goes through the portal’s own API, which is development work rather than a setting.
- Every task carries a named owner, and your own people hold their own accounts — there is no cap on how many
- Policy, procedure, register and evidence work is ours, and we do it rather than hand it over
- A configuration change belongs to whoever holds the credentials; we write it up, order it and follow it
- An external provider can work from their own service desk, with status, notes and evidence coming back to the task
Short, mid and long term, with real dates on the part that has to move first
Two hundred tasks ordered by severity is not a plan, it is the same backlog with a better sort on it. The roadmap puts the work into three horizons, against what your team and your budget can take in a year.
- 01
Short term
A month to a quarter. The critical findings, whatever an auditor would open with, and the structural wins that are cheap now and expensive later. These carry due dates, and those dates are what the weekly call is held against.
- 02
Mid term
A quarter to a year. Work that needs a budget line, a procurement cycle or a change window — and work that only makes sense once the short-term tasks have landed underneath it.
- 03
Long term
Beyond a year. Capability rather than repair: the items that need an organizational change, a platform migration or a headcount decision before they can even be planned properly.
Six states, and only one of them moves your score
Not started, in progress, in review, done, deferred, or not applicable. The interesting distinction is between the last three, because that is where a plan either stays honest or quietly stops being one.
Done is what moves your compliance score, and a task reaches it through review rather than straight from in progress: your vCISO checks the work and the evidence behind it before it counts for anything.
Deferred means the risk was accepted instead of fixed. The task stops asking for attention, and the risk itself stays in the risk register and stays counted against you — a deferral is a decision, not a disappearance. Not applicable means genuinely out of scope, with the reason written on the task, because an unexplained N/A is the easiest thing in the plan for an auditor to pull on.
The proof sits on the task, not in a folder somebody has to find
An auditor rarely asks whether you have a policy. They ask whether you can show the thing happening — the review that was held, the test that was run, the document that was approved — and when it happened. So evidence belongs to the task that produced it, with the file attached and the date it arrived recorded next to it.
Which means there is nothing to assemble when an audit starts. The trail is a by-product of doing the work rather than a week spent searching mailboxes, and each task also carries what it was for: the policy it serves, the frameworks it answers to, and the risks it brings down.
Access reviews and backup tests are scheduled, not remembered
A good part of what a framework asks for is not a change you make once. Access rights get reviewed, backups get restored to prove that they can be, policies get re-approved, suppliers get re-assessed — and every one of those is a control that fails the moment the person who used to remember it leaves.
So they are set up as repeating tasks with their own cadence, and the evidence builds up cycle by cycle instead of in the week before the audit. That is also the only version that shows an assessor a control operating, as opposed to a control that existed once.
A task marked done that a scan still flags comes back for review
Marking a task done is a claim, and for anything externally visible the claim can be checked. Scan findings are read back against the task list, and a finding still present after its task closed brings that task back for review — rather than sitting in a separate report that nobody reconciles with the plan.
It is a small mechanism against an expensive class of mistake: the change made on one server and not the other, the setting that reverted at the next deployment, the exception somebody added for a week two years ago.
Frequently asked questions
The questions we hear most often from security and IT leaders.
Something not covered here? Ask us directly
No, and the roadmap is where that boundary is written down rather than assumed. We produce the task, the procedure and the sequencing; the change itself is made by whoever holds credentials for the system, which is your IT team or your provider. Everything that is governance rather than configuration is ours and gets delivered rather than delegated back — the documents, the registers, the evidence store, the mock audit, preparing your people for audit interviews. When a task is marked done we review it before it counts for anything, and that review is what keeps the two halves honest with each other.
Not necessarily. A task can be mirrored as a ticket in their own service desk and stays linked to the task here, so your provider works where they already work — and the link runs both ways: a status change, a note or an evidence file added on their ticket comes back onto the task. Seven desks are supported out of the box, which covers most providers we meet: ConnectWise, ServiceNow, Autotask, HaloPSA, Kaseya, NinjaOne and Atera. Anything else connects through the portal’s own API, which is development work rather than a setting. Two things worth knowing either way: it syncs on a schedule rather than the instant something changes, so the honest expectation is “within the hour” and not “live” — and where nobody wants to connect anything, the task still reaches them, carried by email and the weekly call.
Like a decision, provided it was one. Deferring a task is the same act as accepting the risk underneath it: it needs a reason, a named person and a date, and the risk stays in the register at its real score instead of quietly leaving the picture. An auditor seeing that reads a management decision they can agree or disagree with, which is a conversation. What they are hunting for is the other version — a task that went quiet with no reason recorded, or a finding marked not applicable with nothing written after it. Those are the two cheapest findings in any audit and both are avoidable in about a minute each, at the time.
Nobody finishes them in a year, and a plan that assumes you will is not a plan. Two things make the number workable. First, a large part of any starting list does not apply to you — the card-payment controls if you take no cards, the secure-development controls if you write no software — and marking those out with the reason is real work that happens in the first weeks. Second, what remains is ordered rather than listed: the critical and short-term tasks carry dates, the rest sits in horizons you revisit each quarter against what actually moved. What your management reviews is never the backlog. It is the decisions for the next quarter.
Where this sits, and what comes next
Scanning
What an attacker sees from outside, what the directory looks like inside, monthly.
Business continuity
Which processes you cannot lose, for how long, and what that costs per month.
Ready to get started?
Partner with Spirity Enterprise to implement the right security and IT solutions for your organization.