Understand your obligations. Build a clear path to compliance.

Because you asked three people about three different laws. NIS2 is a directive, so it does not bind you directly — it binds you through your own country’s implementing act, and the thresholds, the registration duty and the audit regime differ by member state. That is the single most useful thing to understand about it, and it is why the answers disagreed.

The stable part is the directive’s own structure. You are in scope if you operate in one of the listed sectors and you are a medium-sized enterprise or larger — broadly 50 or more staff, or turnover above €10 million. Above roughly 250 staff or €50 million in one of the high-criticality sectors you are an essential entity; most of the rest are important entities, and the difference is how closely you are supervised rather than whether the duties apply. Some entities are in regardless of size, including DNS and TLD operators, trust service providers and public electronic communications.

The determination is a scoping exercise with a written answer at the end of it, signed off by management rather than assumed. It is the first thing we produce.

You build once and prove three times.

The build overlaps heavily. One control set, one asset and supplier register, one evidence store and one risk process serve all three: ISO 27001’s Annex A covers most of what NIS2 Article 21 asks for, and DORA’s ICT risk management chapter is recognisably the same material with financial-sector specifics on top.

What does not merge is the proof. ISO 27001 is certified by an accredited body. NIS2 is supervised by a national authority under national law. DORA is supervised directly by your financial regulator. Three audiences, three mechanisms, three sets of evidence drawn from the same underlying work.

The platform behind our advisory practice scores your posture against each framework separately from the same set of answers, which is what makes “build once” real rather than aspirational.

An assessment, and it produces two documents: a scope statement and a gap analysis.

Scope is the step people skip and the one everything else rests on — which legal entity, which systems, where the boundaries run. It is approved by management, not assumed by us.

The gap analysis runs off structured questionnaires with your IT and security owners, external scanning of your internet-facing addresses and services, and internal review of identity, endpoint and cloud configuration. What comes back is your posture scored against the framework you are actually held to, the gaps ranked by risk and urgency rather than listed alphabetically, and a plan with an owner and a date against every task.

You can buy the assessment on its own as a paid one-off if you want the picture before committing to a programme.

If you have an audit or a supervisory date, plan on about six months of concentrated work. Our readiness programme is built to 180 days for exactly that reason: roughly the first month on scope and gap analysis, three and a half months building and correcting, the last six weeks proving — evidence organised, an internal mock audit, and a reasoned go or no-go put to leadership before the real thing.

If your date is further out the same sequence stretches. The order does not change.

The honest cost is not our time, it is yours. Expect one to one and a half days a week from IT operations through the build phase, because somebody inside your organisation has to make the changes and demonstrate them. Where 180 days is not enough for everything, the findings are split into audit-critical and achievable, audit-critical but longer — started immediately, with a compensating control and progress on file — and not audit-critical. Your management approves that split at the sixty-day mark rather than discovering it at the end.

We do. Policies, procedures, the system security plan and the asset, data and supplier registers behind them are our work — generated against your actual environment and the framework you are held to, then tailored. Not a template pack with your logo on it.

What stays with you is implementation. We can specify that MFA is enforced, verify it, and write the evidence that it is — but somebody with access to your systems has to make the change. We do not touch your systems.

That boundary is deliberate, and we would rather you knew it before signing than discovered it in month two.

Under NIS2 it is specific: the management body has to approve the cybersecurity risk-management measures, oversee their implementation, and undergo training — and members can be held personally liable for failures. For an essential entity the sanctions reach a temporary ban on the chief executive or legal representative exercising managerial functions. DORA says the same thing in its own words: the management body carries final responsibility for ICT risk and must keep enough knowledge to exercise it.

In practice, proving it means a documented trail — approvals with dates, minuted decisions, a training record, and a report that shows what changed between one period and the next.

What you get is that trail as a by-product of the work rather than something assembled the week before a board meeting: a monthly management report on progress against milestones, open risks, and the decisions we need from you, plus a periodic management review that sets the new report against the old one. It comes out of the same system that runs the work, so it cannot quietly diverge from it.

No, and we could not even if we wanted to. Certification is issued by an accredited certification body after a two-stage audit, and the accreditation rules require that a firm which consulted on your management system stays out of certifying it. The same separation applies to the NIS2 audit, which is performed by a registered independent auditor whose fee is not part of ours.

What we do is everything up to the auditor’s door, and then stand beside you at it: build the management system, run an internal mock audit using the real audit’s own method — document review, sampled evidence, interviews, controls demonstrated rather than described — prepare the people who will be interviewed, give leadership a go or no-go with reasons, and coordinate the official audit.

We can tell you not to go, and sometimes do.

We hold ISO/IEC 27001 ourselves, certified in early 2025 through a UKAS-accredited body and scoped to our own operation as a managed security service provider. So we have been through it from your side of the table.

No. The clock is on the entity, and no monitoring contract moves it.

NIS2 requires an early warning to your national authority within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. DORA is tighter for major ICT incidents, on the regulator’s own templates.

A security operations centre detects, triages and tells you. The judgement that an incident is significant, the submission itself, and the consequences of a late or wrong one remain yours. Managed-service contracts say so in writing: retaining logs for regulatory purposes is the customer’s responsibility, and platform output is explicitly not a substitute for the customer’s own legal and regulatory judgement.

What actually closes the gap is the plumbing between the two — a classification rule set agreed in advance against the criteria your regulator uses, a named decision-maker reachable at three in the morning, notification content drafted before you need it, and the whole path rehearsed once while nothing is on fire. That is governance work, and it is what the advisory engagement is for.

Three things, in rising order of unpleasantness.

First, contract. NIS2 obliges your customer to manage supply-chain risk, so their duties arrive at your door as security clauses, questionnaires, audit rights and incident-notification terms. That is the usual route, and it is enforceable against you as contract law rather than regulation.

Second, check the size and sector test again, because “not regulated” is frequently wrong. Managed ICT service providers, cloud, data centre, CDN and trust service providers are themselves named sectors under NIS2 — an IT supplier to a regulated company is quite often in scope in its own right.

Third, if your customers are financial entities, DORA can reach you directly. Providers designated as critical by the European supervisory authorities come under an EU oversight framework, and every financial customer must list you in a register of information filed with its regulator, on prescribed contract terms.

Practically: the first step is the same scoping exercise, and the second is being able to answer supplier questionnaires with evidence instead of assertions. That is considerably cheaper than failing them.