Who should read this: the person in a company of thirty to two hundred and fifty who was handed security a few weeks ago, on top of the job they already had, with no budget line, no team, and a customer questionnaire or a registration form already waiting.
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 a body of work nobody has scoped, in time nobody has allocated.
Ninety days is the right unit to plan in: long enough to reach a defensible position, short enough that you cannot fill it with documents. What follows assumes one person, two to eight hours a week, and no prior security function.
Why ninety days, and not twelve months
The clocks are not yours to set.
In Luxembourg, the Law of 5 May 2026 entered into force on 10 May 2026, and Article 11(4) gave in-scope entities two months to communicate their name, contact details, sector, subsector and size to the competent authority. That window closed on 10 July 2026, and changes must be notified within two weeks. Registration is not a security control, it is an administrative act with a fine attached: administrative breaches under Article 25, including failures around registration, carry fines up to EUR 250,000. Who reports what, and to which authority, is in how the Law of 5 May 2026 transposes NIS2.
Elsewhere the picture is messier, and 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, asking for lump sums and daily penalties. A supplier in one of those four still receives the same customer clauses, because the clauses come from the customer’s obligation, not from 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 one to fifteen: establish what is true, not what is intended
Two questions, both answerable in a fortnight, both usually answered wrongly from memory.
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. In most companies where security has just been handed to someone, nobody did.
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, including the ones bought on a card by a team lead 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, and those are the findings that make the rest of the ninety days credible internally.
Days fifteen to thirty: take the decisions that are already being made without you
Security in a company without a security function 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 and four will not be fixed, so somebody has to say that is acceptable.
Before the appointment, those decisions were made inconsistently and not written down. The highest-value thing you can do in the second fortnight is route them to one place, which is now you, and record the answer. The argument for a named owner, 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, because it is evidence of a process rather than evidence of a document.
Days thirty to forty-five: one inventory, one owner per thing
Go back to the list and add two columns: who owns this, and what happens if it stops. Ownership means a named person, not a team, because teams do not renew certificates. The exercise surfaces the systems nobody owns, reliably the ones with the oldest credentials and the widest access.
While you are in the list, reconcile access against reality. Pull the user list from each significant system and compare it against current payroll and current contracts. In every company that has never done this the result is the same: accounts belonging to people who left, contractors whose engagement ended, and at least one shared login whose password is in a chat history. Access is granted carefully and revoked from memory, which is why this reconciliation is the control most often tested and most often failed.
Days forty-five to sixty: 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 requirement is what turns a register from a spreadsheet into a governance artefact, and it is the difference between the two kinds described in the risk register that survives an audit.
Days sixty to seventy-five: 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, and 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: the inventory in one page, the ten risks, the three being treated this quarter with the sums involved, the four being accepted and why, and 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, and puts accountability where the directive already puts it. The mechanics of approval, oversight and the training duty are in board accountability under NIS2.
Days seventy-five to ninety: 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 discovering how long the answer takes to produce. Two days of manual collection now is two days every time it is asked, and it will be asked by every customer, every year. That arithmetic is the argument for evidence that regenerates rather than evidence you assemble, which is the distinction in evidence that assembles itself.
What to refuse in the first ninety 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, and 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 to tell at day ninety whether it worked
Not by document count. By four tests, each answerable yes or no.
- Can you produce the list of systems and their owners in under an hour, from something maintained rather than from memory?
- Is there a dated record of every security decision taken in the last two months, and the reason?
- Has the management body approved something in writing, with the residual risks named?
- 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, but 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, and it usually means the appointment came without the hours. 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.
The technical reality: ninety days of governance cannot see your estate
Everything above produces intent. Documented, approved, dated intent, which is exactly 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, that a dependency has a known vulnerability, or that an account that should have closed in March is still in use.
That is the gap governance leaves open, and it is narrow enough to describe precisely. Closing it means the asset list is generated from the estate rather than typed into a spreadsheet, the access list reconciles itself against HR and contract records continuously, vulnerabilities in what you actually run reach you as ranked findings with a recommended action, and the evidence a customer asks for is produced by the work rather than assembled the week before. That runs continuously and automatically, 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 is what keeps the answers true in month four, when the person who owns security is busy with the job they had before.
