vCISO first 90 days: the plan for a part-time security owner

A vCISO or part-time security owner’s first 90 days should produce four things you can prove, not forty policies: a maintained list of systems and owners, a dated decision log, a board approval naming the residual risks, and one customer question answered from system records. The plan assumes one person, two to eight hours a week, and no prior security function.

This guide covers why ninety days, the six fifteen-day phases, what to refuse, the four day-90 tests, and what governance cannot see.

Days	Focus	What you have at the end
1 to 15	Scope, registration, what you have	A first list of systems
15 to 30	Route security decisions to one place	A dated decision log
30 to 45	One owner per system, access reconciled	A named person per system
45 to 60	Risk register	Ten to fifteen risks written as scenarios
60 to 75	Decision paper to the board	A minuted approval
75 to 90	Prove one thing end to end	One answer from system records, and its cost in time

Why plan the first 90 days, not the first year?

In a company of thirty to two hundred and fifty, the appointment is rarely formal. A contract arrives with a security annex, or a customer asks who the security contact is, and a name goes in the box. That name is now accountable for work nobody has scoped, in time nobody has allocated.

Ninety days is long enough to reach a defensible position, and short enough that you cannot fill it with documents. And the clocks are not yours to set.

Registration is not a security control, it is an administrative act with a fine attached. In Luxembourg the window closed on 10 July 2026, as set out in how the Law of 5 May 2026 transposes NIS2. Elsewhere the mess is not a reprieve. On 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify complete transposition. A supplier there still receives the same customer clauses, because the clauses come from the customer’s obligation, not the supplier’s national law.

So the ninety days are not a self-imposed sprint. They are the window before the next thing with a date on it.

Days 1 to 30: what should a new security owner do first?

Days 1 to 15: establish what is true, not what is intended

Two questions, both answerable in a fortnight, both usually answered wrongly from memory.

1. Are you in scope, and are you registered? Scope turns on sector and size, with size-agnostic categories underneath that catch companies who assume they are too small. The NIS2 scope checker takes a few minutes, and the scope and applicability guide explains the categories behind the answer. Then find out whether anyone registered. Where security has just been handed to someone, usually nobody did.
2. What do you actually have? Not the diagram, the list. Every system holding customer data or running a production service, every SaaS tool with a corporate login, every cloud account, repository and domain. Include the ones a team lead bought on a card in 2023.

You will not finish the list in fifteen days. You will finish enough of it to find the two or three things nobody knew were still running. Those findings make the rest of the ninety days credible internally.

Days 15 to 30: take the decisions already being made without you

Without a security function, security is a stream of small decisions made by whoever they land on. An engineer wants admin rights for a week. A supplier questionnaire has a deadline. A penetration test came back with eleven findings, four will not be fixed, and somebody has to say that is acceptable.

Until now, those decisions were made inconsistently and not written down. The most valuable thing you can do in the second fortnight is route them to one place, which is now you, and record the answer. Why a named owner matters, and what happens without one, is in who owns security when nobody owns it.

Keep it light: one running log, each entry with a date, a decision and who asked. Three months of that log is worth more at an audit than three months of policy writing. It is evidence of a process, not evidence of a document.

Days 30 to 60: how do you build the inventory and the risk register?

Days 30 to 45: one inventory, one owner per thing

1. Add two columns to the list: who owns this, and what happens if it stops. Ownership means a named person, not a team, because teams do not renew certificates. The systems nobody owns are reliably the ones with the oldest credentials and the widest access.
2. Reconcile access against reality. Pull the user list from each significant system and compare it against current payroll and current contracts.

Where this has never been done, the result is the same: accounts of people who left, contractors whose engagement ended, and a shared login whose password is in a chat history. Access is granted carefully and revoked from memory, which is why this is the control most often tested and most often failed.

Days 45 to 60: a risk register that can survive being read

Now, and not before, write the risk register. Before the inventory it is fiction.

Keep it short: ten to fifteen risks a person in the company would recognise as real, each written as a scenario rather than a category. “Ransomware” is a category. “Our build server has a local admin account shared by four engineers and no offline backup” is a risk.

The guidance is unusually specific about what an entry has to carry. ENISA’s Technical Implementation Guidance of 26 June 2025, on Commission Implementing Regulation (EU) 2024/2690, expects a risk treatment entry to record:

• the risk and the objective
• the treatment option
• the assets affected
• the mitigating measures
• how effectiveness will be assessed
• the timeline and the responsible role

Point 2.1.2(j) adds the part most registers miss: where residual risk is accepted, the reasons have to be recorded in a comprehensible manner. That turns a register from a spreadsheet into a governance artefact, the difference set out in the risk register that survives an audit.

Days 60 to 90: what does the board have to approve?

Days 60 to 75: hand the board the part that is legally theirs

NIS2 makes the management body approve the risk management measures, oversee their implementation, and be liable for infringements. That is not delegable to you. A part-time owner who absorbs it has taken on personal exposure for a decision that was never theirs.

So prepare one paper and put it on an agenda. Not a status update, a decision paper:

1. The inventory in one page.
2. The ten risks.
3. The three being treated this quarter, with the sums involved.
4. The four being accepted, and why.
5. What you are asking them to approve.

Minute the approval. Doing this at day sixty rather than day two hundred and sixty converts an informal appointment into a mandate with a budget conversation attached. It puts accountability where the directive already puts it. The mechanics of approval, oversight and the training duty are in board accountability under NIS2.

Days 75 to 90: prove one thing end to end

Pick one question a customer or an auditor will ask, and answer it fully with evidence rather than assertion. A good one: show that every person who left in the last six months no longer has access to anything, from system records rather than an offboarding checklist.

The point is not the answer, it is how long the answer takes to produce. Two days of manual collection now is two days every time it is asked, and every customer will ask, every year. That is the argument for evidence that regenerates rather than evidence you assemble, the distinction in evidence that assembles itself.

What should you refuse in the first 90 days?

Three things will be suggested, and all three are wrong this early.

• Writing the full policy set. Forty policies written by one person in three months are forty documents nobody has read. An auditor finds the gap between them and practice in the first hour. Write the three that describe what you actually do.
• Starting an internal audit. Clause 9.2 wants a programme, and a programme audits a system that exists. Auditing a control set you built six weeks ago tells you nothing new. The sequencing, and the independence problem that makes it expensive in a small company, is in internal audit and management review.
• Buying a platform before the inventory. Tooling applied to an unknown estate produces a confident dashboard describing part of your company.

How do you know at day 90 whether it worked?

Not by document count. By four tests, each answerable yes or no.

1. Can you produce the list of systems and their owners in under an hour, from something maintained rather than from memory?
2. Is there a dated record of every security decision taken in the last two months, and the reason?
3. Has the management body approved something in writing, with the residual risks named?
4. Can you answer the access question end to end from system records?

Four yeses is a defensible position for a company with no security team. It is not certification and it is not maturity. It is the base every subsequent framework sits on, and roughly where ISO 27001 without a security team begins.

Four noes is also useful information. It usually means the appointment came without the hours, and a named owner with no time is the same as no owner, described differently. The fix is either hours or a vCISO arrangement that puts the judgement calls with someone who does this weekly.

What can ninety days of governance not see?

Everything above produces documented, approved, dated intent. That is what the frameworks ask for and what an auditor will accept. None of it tells you what is happening on your systems.

The inventory is a snapshot taken by hand and starts drifting the day after it is finished. The access reconciliation is true on the morning you did it. The risk register describes what you thought of in a room in week seven. A company can complete a clean ninety days and still not know that a build server is exposed, or that an account that should have closed in March is still in use.

Closing that gap means the asset list is generated from the estate, and the access list reconciles itself against HR and contract records. Vulnerabilities in what you run arrive as ranked findings with a recommended action. Evidence is produced by the work, not assembled the week before. That runs continuously, with nothing to install on your side, and it is what the platform carries alongside the governance record. Ninety days of the work above makes a company audit-ready. The technical half keeps the answers true in month four, when the security owner is busy with the job they had before.

90-day checklist for a part-time security owner

• Check whether you are in scope, and whether anyone registered.
• List every system, SaaS tool, cloud account, repository and domain, including the ones bought on a card.
• Start one decision log: date, decision, who asked.
• Name a person, not a team, as the owner of each system.
• Reconcile each significant system’s users against current payroll and contracts.
• Write ten to fifteen risks as scenarios, with the reasons for every accepted residual risk.
• Put one decision paper to the board, and minute the approval.
• Answer the leaver-access question from system records, and time how long it takes.

Frequently asked questions