CyFun and assurance levels
CyFun is the most concrete framework a Belgian organization can follow, because it states per level what is expected of you instead of leaving it to interpretation. The step where organizations most often run aground on their own comes before all of that: establishing which level applies.
This page explains how the level is established, how CyFun and ISO 27001 relate to each other, and what the conformity assessment expects of you.
Frameworks that describe objectives leave organizations to work out for themselves what is enough. CyFun takes a different route: it sets out concrete measures, grouped per assurance level, so that an organization can see what belongs to its level and what does not. For a board that is a considerable advantage, because it turns an open ended security discussion into a defined scope of work.
It also travels well. The structure follows an internationally recognised model, so the work done for CyFun is not lost if an organization later moves towards certification or has to answer a client's security requirements. That is worth knowing at the start, because it removes the fear of building something purely national and disposable.
This is where we see the most avoidable mistakes. An organization decides that basic feels proportionate, or that essential sounds safest, and starts implementing. Neither is a determination. The level follows from the grounds that apply to your organization, and those grounds are a matter of fact rather than ambition or comfort.
The cost of getting it wrong runs in both directions. Aim too low and the foundation falls away at the moment it is assessed, with the implementation work that rests on it. Aim too high and you commit budget and attention to measures nobody asked of you, which is usually paid for out of the budget the organization genuinely needed elsewhere.
The determination is not a single judgement but a series of them. Several grounds can bring an organization within the framework, each is assessed separately, and where they lead to different outcomes the highest applies. That rule is simple to state and routinely skipped, because it takes work to go through every ground rather than settling on the first one that looks right.
Our recommendation is to document the reasoning per ground, including the grounds that do not apply and why. That document is what makes the level defensible later, in front of an assessor, a supervisor or a client. It is also what makes it revisable: when an activity, a client or a service changes, you can see immediately whether the conclusion still holds.
Organizations often present this as a choice. In practice the two fit together. An established management system built on ISO 27001 covers much of what CyFun asks, provided the scope and the statement of applicability are mapped onto the CyFun measures rather than assumed to cover them.
Which combination is right depends on where you are and what your clients ask of you. An organization that already holds a certificate should be looking at the mapping, not starting again. An organization with nothing in place is usually better served by starting from the measures that its level asks for and growing towards a management system, rather than the other way around. Our page on ISO 27001 goes into what that system actually requires.
Verification of conformity is not a document review. An assessor looks for evidence that the measures are in place and working, and the quality of that evidence is decided long before the assessment, in how the organization set up its records. Measures that exist only in policy consistently take the most time to remediate.
There is also a choice of route. Conformity can be demonstrated through a CyFun verification or certification, through an ISO 27001 certification supported by a mapping onto the applicable key measures, or through an inspection by the authorities following a self assessment. Which of the three fits depends on what your clients ask of you, what you already have in place and how much independent assurance your board wants on the outcome.
The practical consequence is that evidence should be a design requirement from the start. When we help organizations prepare, the first question is not which measures are missing but which of the measures already in place could actually be demonstrated tomorrow.
Before touching a single measure, establish your level and write down the reasoning behind it, ground by ground. Have the management body confirm it. Everything after that, the gap assessment, the roadmap and the budget, follows from that one decision, and redoing it later is expensive in a way that the determination itself never is.