How Much Work Is CyFun Basic? A Real 11-Week Implementation, Measured
Belgium has more than 4,000 entities registered under NIS2, and most guidance about implementing CyberFundamentals speaks in months and consulting budgets. We had a rarer thing: a real implementation, fully instrumented. Every action in our platform is an event with an actor and a timestamp, so instead of asking anyone how long it took, we exported the log and counted. One honesty note up front: think of the platform as a scoreboard, not the gym. It records the moment something is registered; the real-world work behind each entry, and the many hours of it, happens off the platform where no log can see it.
Eleven weeks at one day a week: the activity calendar
Read these like a GitHub contribution graph: one cell per day, darker is more. The green calendar is the human: 26 sessions, roughly one real work day per week, with one heavy inventory day on 11 May. The blue calendar is the platform: once integrations were connected (8 to 18 May), automated evidence collection keeps running whether anyone logs in or not.
What happened, in four phases
1. Scoping (30 March, one morning)
Onboarding, the CyFun level check and the first policy skeletons. The framework check recommends BASIC for this organisation's size and risk profile.
2. Intake (April)
The guided intake assessment: 90 answers about how the organisation actually works. On 20 April the platform sets a first maturity baseline across all 34 controls.
3. Build (May)
The heavy weeks. Asset inventories arrive through integrations and one CSV import; the implementer decides what is business-critical, finalises 8 policies and procedures, and connects Microsoft 365 and endpoint security integrations. From 21 May, automated evidence collection is live.
4. Judge and close (June)
The part only a human can do: reviewing each control, accepting or correcting scores, and asking an expert where legal interpretation was needed. Final state on 17 June: 31 of 34 controls audit-ready, 3 expected to fail, honestly labeled as such.
Where the 672 manual actions went
None of the big blocks require security expertise. They require knowing your own organisation.
| Type of work | Manual actions |
|---|---|
| Deciding what is business-critical (grouping assets and people) | 153 |
| Handling evidence (upload, link, review) | 133 |
| Answering the intake assessment | 90 |
| Onboarding and policy skeletons | 67 |
| Writing policies and procedures (8 documents) | 64 |
| Register edits and CSV imports | 60 |
| Maturity scoring and acceptance | 30 |
| Everything else (exports, integration connects, exceptions) | 25 |
Actions recorded under user accounts by integration syncs and the platform's own processing are counted as automation, not as manual work.
What the platform did on its own
For every manual action, the platform performed seven. The asset registers (devices, people, applications) were written and kept current by integration syncs; the implementer's register work was about 60 edit and CSV actions, most of it on a single day. 19 of the 34 controls ended the project fully scored from automated evidence, with no manual override.
Since automated evidence went live on 21 May, the platform has materialised more than 1,300 evidence records on its own. That is the part that matters after the project ends: build effort happens once, but evidence freshness is what an auditor checks. The 19 automated controls stay current without anyone spending a Friday on screenshots.
Where a non-specialist hit a wall
One pattern deserves honesty. The control that took longest from first touch to sign-off (GV.OC-03.1, the legal and regulatory register) was also the one where the implementer explicitly needed expert input, twice. Deciding which laws apply to your organisation is not a punch-list task. Technical and procedural controls were completed without that help. This is one observation from one implementation, not a law of nature, but it matches how we think the work should split: automation and guidance carry the routine majority, expert time goes where judgment is scarce.
Modeled: integrations connected on day one
This implementation was mixed-mode: inventories were first built by hand and CSV import (the heavy inventory day on 11 May), then integrations took over. Modeled on the measured data, connecting integrations in week one removes most of that day's register work. But the bigger difference is not the build time. It is that once integrations are live, inventories and evidence stay continuously up to date afterwards, without anyone logging in.
All 34 controls: outcome and timeline
Every control got its first score on 20 April. The last-activity column shows which controls needed a human to come back in June, and which ones automation closed early.
| Control | What it covers | Outcome | First / last activity |
|---|---|---|---|
| GV.OC-03.1 | Legal & regulatory register | Human judged | 20 Apr → 9 Jun |
| GV.PO-01.1 | Policy framework | Automated evidence | 20 Apr → 9 Jun |
| GV.RM-03.1 | Risk strategy | Automated evidence | 20 Apr → 7 May |
| GV.RR-04.1 | Authentication for critical access | Human judged | 20 Apr → 5 Jun |
| ID.AM-01.1 | Hardware inventory | Automated evidence | 20 Apr → 8 May |
| ID.AM-02.1 | Software inventory | Automated evidence | 20 Apr → 7 May |
| ID.AM-5.1 | Asset prioritisation | Human judged | 20 Apr → 8 Jun |
| ID.AM-07.1 | Data identification | Human judged | 20 Apr → 9 Jun |
| ID.AM-08.2 | Patching | Automated evidence | 20 Apr → 7 May |
| ID.RA-01.1 | Threat & vulnerability identification | Automated evidence | 20 Apr → 2 Jun |
| ID.RA-05.1 | Risk assessment | Automated evidence | 20 Apr → 22 Apr |
| ID.IM-03.1 | Post-incident lessons | Automated evidence | 20 Apr → 22 Apr |
| PR.AA-01.1 | Identity & credential management | Automated evidence | 20 Apr → 7 May |
| PR.AA-03.1 | Wireless access points | Human judged | 20 Apr → 2 Jun |
| PR.AA-03.2 | Remote MFA | Human judged | 20 Apr → 4 Jun |
| PR.AA-05.1 | Access permissions | Automated evidence | 20 Apr → 7 May |
| PR.AA-05.2 | Access needs determination | Human judged | 20 Apr → 9 Jun |
| PR.AA-05.3 | Least privilege | Automated evidence | 20 Apr → 7 May |
| PR.AA-05.4 | No routine admin rights | Human judged | 20 Apr → 5 Jun |
| PR.AA-06.1 | Physical access | Automated evidence | 20 Apr → 7 May |
| PR.AT-01.1 | Awareness & training | Human judged | 20 Apr → 28 May |
| PR.DS-01.9 | Asset disposal | Automated evidence | 20 Apr → 7 May |
| PR.DS-11.1 | Off-system backups | Human judged | 20 Apr → 5 Jun |
| PR.PS-04.1 | Log monitoring | Human judged | 20 Apr → 9 Jun |
| PR.PS-05.1 | Web & e-mail filters | Automated evidence | 20 Apr → 28 May |
| PR.IR-01.1 | Firewalls | Automated evidence | 20 Apr → 7 May |
| PR.IR-01.2 | Network segmentation | Human judged | 20 Apr → 5 Jun |
| DE.CM-01.1 | Boundary & endpoint firewalls | Automated evidence | 20 Apr → 2 Jun |
| DE.CM-01.2 | Anti-malware | Automated evidence | 20 Apr → 5 Jun |
| DE.CM-03-1 | Behaviour monitoring | Automated evidence | 20 Apr → 22 Apr |
| DE.AE-03.1 | Detection log review | Automated evidence | 20 Apr → 22 Apr |
| RS.MA-01.1 | Incident response plan | Human judged | 20 Apr → 5 Jun |
| RS.CO-02.1 | Incident communication | Human judged | 20 Apr → 5 Jun |
| RC.RP-01.1 | Recovery process | Human judged | 20 Apr → 15 Jun |
Outcome per the 29 June state; control states keep moving as automated evidence updates. The 91% headline is the dated 17 June assessment, which flagged 3 controls as expected to fail their audit. Audit-ready means the evidence would plausibly survive a CAB auditor's review; the audit itself is performed by an accredited CAB.
What this means if NIS2 applies to you
- 1 If you are a small entity dreading a consulting quote: this ran over about eleven weeks at roughly one day a week. It is a project, not a career change. Most of the real effort is configuring your environment and writing your procedures, off the platform; the platform's job is to tell you exactly what is needed and prove it once you have done it.
- 2 If you are an MSP or IT partner: a junior can run this for your clients. What you actually sell is the judgment layer: criticality decisions, policy sign-off and the legal questions, not the data entry.
- 3 If you want data rather than promises: every implementation on the platform is instrumented the same way. Ask for the method, or measure your own.
Frequently Asked Questions
Is 91% audit-ready the same as being NIS2 compliant?
No. Audit-ready means each control has implementation plus evidence that would plausibly survive a CAB auditor's review, as assessed in the platform. The audit itself is performed by a Conformity Assessment Body. The 17 June assessment also flagged 3 of 34 controls as expected to fail, visible and honestly labeled rather than hidden.
Can someone without a cybersecurity background really do this?
This implementation is an existence proof that it happened once: a person with no prior cybersecurity or compliance experience, guided control by control, at about one day per week. Where they needed help was specific: legal interpretation (which laws apply). Technical and procedural work was completed without expert input.
Does one implementation prove this works for everyone?
No, and we do not claim it does. This is one measured case, published with its method and limits. Every implementation on the platform is instrumented the same way, so the dataset grows with each one. We would rather publish one honest datapoint than an unverifiable average.
What stays manual even with full automation?
Knowing your own organisation: deciding which assets and people are business-critical (the single biggest block of manual work, 153 actions), reviewing and accepting maturity scores, policy content decisions, and the questions that need legal interpretation. Automation writes and refreshes inventories and evidence; it does not know what matters to your business.
Why don't you report the hours of effort?
Because we cannot measure them honestly. The platform stores every change as a timestamped event, so we can count actions (672 manual) and the days they fell on (26), but not the minutes between them. The implementer was also running a help desk at the same time, so a day's span is not time spent on compliance. The bigger reason: the real work leaves no event at all. Turning on MFA, installing firewalls, writing and running procedures, gathering proof. That happens off the platform. So we report the timespan and the counts, which we can defend, and leave the stopwatch alone.
What did the three not-audit-ready controls need?
Real-world organisational changes that software can flag but not perform. The platform marks such controls as expected to fail rather than dressing them up, because an honest 91% with a to-do list beats a fake 100%.