Targeting CyFun Essential as a solo founder: start from the threat, not the stamp

A SaaS product that stores valuable data — identities, contact details, accounting, its users' decisions — is a target. Not because it's well known: because that data can be resold, held to ransom, or used to commit fraud. The size of the vendor changes nothing. An attacker doesn't look at your headcount, they look at what they can extract.

That's why I set a deliberately high target for the two building blocks of the method I co-develop: Foyer, for how things are designed and built, and Sluis, for how they are deployed and operated. Any SaaS product that comes out of them must be able to align with the most demanding level of Belgium's CyberFundamentals framework: the Essential level.

Here's why, how I break it down — and, the part nobody talks about, what a solo founder can and cannot do alone.

CyFun in two minutes

CyberFundamentals (CyFun) is the framework published by the Centre for Cybersecurity Belgium (CCB). Its 2025 version is built on the NIST Cybersecurity Framework 2.0 and serves to demonstrate NIS2 compliance; it coexists with the 2023 version until 18 April 2027.

It is organized into cumulative levels — Small, Basic, Important, Essential. Targeting Essential means satisfying the last three at once:

Two things to keep in mind:

• Key measures are the ones the CCB makes mandatory priorities because they block the most frequent real-world attacks. They must be in place whatever your risk analysis concludes.
• Compliance isn't measured in ticked boxes but in maturity, out of 5. Doing the thing isn't enough: you need a written, approved, applied process — and evidence.

Why the most demanding level, when nothing requires it of me

In principle, an organization's CyFun level follows from a national risk analysis, and a solo founder generally falls outside NIS2. I target Essential by choice, for three reasons.

I start from the threat. List the realistic attacks against a data-rich SaaS product and you land very quickly on measures that only appear at the Important and Essential levels: isolated and tested backups, logs out of an attacker's reach, audited privileged access, mapped outbound flows. Stopping at Basic protects you against the opportunistic attack, not against the one aimed at your data.

A high target, built once, serves every project. If compliance is carried by the method and by the deployment platform, each new SaaS product inherits it instead of proving everything again from scratch.

The level is a shared language. Saying "aligned with CyFun Essential" to a client, a partner or an auditor means speaking a vocabulary they can go and verify — instead of an unverifiable "we take security seriously".

From the threat to the building block

Here's the full reasoning, attack by attack: the CyFun 2025 measures that counter it, then the block that carries them. In brackets, the measure's level (B = Basic, I = Important, E = Essential) and key when it's a key measure.

The guardrail on that last line

Automating alert triage is tempting, especially with a language model. But the content of an alert can be written by the attacker: a network alert contains the User-Agent and the request of whoever is scanning you. Handing that text to an agent that holds a shell opens the door to prompt injection.

Hence the rule I apply:

• evidence collection is done by a deterministic, read-only script;
• the verdict is written by a model that has no tools at all;
• the notification always carries the raw evidence underneath the verdict;
• no remediation ever follows automatically from that verdict.

In one sentence: what has privileges doesn't read free text; what reads free text has no privileges.

Three layers, so each project inherits instead of re-proving

The ~230 requirements split into three layers, and each has its owner:

• Platform, carried by Sluis: immutable and tested backups, off-host logs, separation between production and test, firewall, privileged access, monitoring wired in.
• Application, carried by Foyer: MFA and identity management inside the product, secure development, dependency vulnerabilities, data flow mapping.
• Organization, carried by documents: policies, risk analysis, incident response plan, supplier management, training.

The idea that changes everything: compliance becomes a deployment gate. Before every release, the platform checks the controls required by the level the project declares — off-site backup active, logs shipping, MFA on the hosting account. If a control is missing, the release is refused. And every deployment leaves dated evidence of the controls verified, tied to its CyFun identifier.

Why that's decisive: maturity 3/5 requires evidence for most activities. Evidence produced automatically at every deployment doesn't get forgotten. Evidence you have to remember to gather before an audit does.

And in euros? On the infrastructure side, the platform layer costs surprisingly little: with a European host, a few tens of euros a month for a small SaaS product — a second machine for testing and monitoring, write-locked object storage in another region, a log platform, a key manager. The real cost is time: writing the procedures, testing the restores, holding the reviews.

Self-assessment: measure before you build

The CCB publishes a self-assessment tool per level, as a spreadsheet. For each requirement you score two values from 1 to 5: documentation (is the process written, approved, reviewed?) and implementation (is it applied, and with what evidence?).

Levels run from 1 (Initial, nothing formal) to 5 (Optimizing, measured continuous improvement). Level 3, Defined, is the threshold that counts: a formal, approved, applied process, evidence for most activities, fewer than 10% exceptions.

For Essential, three thresholds: every key measure (all 29) at 3/5 or above, every category at 3/5 or above, and an overall maturity of at least 2.5/5.

How I run it:

1. Honestly, with evidence behind each answer. A "yes" with no evidence scores 1, not 3. The classic self-assessment trap is scoring what you believe you do.
2. Basic first, since the model is cumulative: there's no point attacking the 91 Essential requirements while a Basic key measure sits below the threshold.
3. The gaps become the backlog. Every requirement below the threshold becomes a task, attached to its layer — platform, application or organization.
4. It gets redone. A self-assessment is a snapshot: you retake it after every significant change, and its evidence ages.

And one clarification I'd rather write myself than have an auditor remind me of: a self-assessment is not a certification. To say "compliant", you need an assessment by a conformity assessment body. "Aligned" is what a self-assessment lets you claim — provided you documented it.

What a solo founder cannot do alone

Around 230 requirements is a framework designed for organizations that have teams. Some requirements assume several people, and no amount of automation replaces that. So let's say it plainly:

• Segregation of duties (PR.AA-05.6, from Important onwards). Whoever requests an access shouldn't be the one granting it; whoever deploys shouldn't be the one checking. Alone, you hold every role. What you can do: replace the second person with controls you can't bypass yourself — deployment only from a commit, a compliance gate, an audit log shipped out of your own reach — and have a trusted third party review periodically. That's a compensating control, to be documented as such, which an assessor may or may not accept.
• Independent assessment (ID.IM-03.7, Essential). Essential requires independent teams to assess your processes; you can't be independent of yourself. What you can do: a budgeted external audit or one-off penetration test. There is no other option.
• Management approval. Level 3 requires "formally approved" processes. Alone, you approve yourself: signing and dating your policies still counts as evidence, but the control value of an approval with no outside eyes is low. Worth knowing.
• Physical security. Critical zones, fire detection, building access control: a solo founder has no datacenter. What you can do: delegate it to the host and prove it through their certifications (ISO 27001 in particular), documented in supplier management.
• Supplier audits (GV.SC-07.3, Essential). You will not be auditing your hosting provider. What you can do: rely on their attestations (ISO 27001, SOC 2 reports on request) and document acceptance of the residual risk. It's also what should guide your choice of host: some qualifications — healthcare, sovereign cloud — don't cover every product line.
• 24/7 response. Nobody can be on call permanently. The realistic goal: no alert gets lost, each one arrives with enough to decide fast, and the incident response plan states what happens when you're unavailable.
• The weight of documentation. This is the real limit. The technical side is built once, and a well-designed platform makes every project inherit it. Documentation has to be written, approved, reviewed and evidenced continuously — and it's what moves you from 2 to 3 on the maturity scale. The only lever that holds for a solo founder: have the tooling produce the evidence rather than writing it by hand.

In short: a solo founder can reach most of the protection the Essential level brings, and get close on maturity. But some requirements assume an organization, and they'll only be satisfied through compensating controls, third parties, or one day a partner. Saying so isn't an admission of weakness: it's exactly what an honest risk analysis is supposed to write down.

What it changes for you

• Your project's security level doesn't depend on how vigilant I am today — it depends on controls that refuse a non-compliant release.
• The evidence already exists the day someone asks for it — client, partner, insurer, auditor — because it's produced at every deployment, not gathered ahead of an audit.
• You inherit the work done on previous projects instead of funding a compliance effort that restarts from zero.
• The limits are written down, not hidden. You know what's covered by tooling, what's covered by a compensating control, and what will need a third party.

Targeting CyFun Essential on your own isn't about chasing a stamp. It's about setting a demanding, verifiable target built from the attacks you actually want to stop, and writing it into the method so every project benefits instead of redoing it each time.

If you'd like to know what that level would look like on your product — or simply where you stand today — let's talk.