Blog: Your policy is fine.
A policy review usually compares two things: what the standard requires, and what your document says.
There is a third axis, and almost nobody measures it. What is actually running.
That omission is why GRC teams can pass a review in March and still be surprised in September. The document was accurate when it was approved. The environment moved on without it, and no process existed to notice.
This piece is about closing that third axis: what an automated policy analysis genuinely does, why "partially covered" is the most useful verdict you can get, and how a review stops being a project and becomes a cycle.
Why a policy is outdated before it is approved
Writing policy takes weeks. Getting it approved takes longer. Somewhere in that window, an engineer adds a firewall exception to unblock a supplier, a conditional access rule gets relaxed after a helpdesk ticket about login friction, and an endpoint exclusion created during an incident stays in place.
Each change is small and locally defensible. Together they produce an environment that no longer resembles the document describing it.
"The document was accurate when it was approved. The environment moved on."
The traditional answer is an annual review. That works if your environment changes annually. It does not, and neither does the standard: CyFun, the Belgian interpretation of NIS2, moved from its 2023 to its 2025 version and changed a substantial share of its controls along the way.
What an automated analysis actually does
Uploading policy documents to a platform sounds like document management. What happens next is closer to an audit.
The first pass is classification. An AI agent validates whether a document relates to cybersecurity at all, then assigns it to one or more categories. This matters more than it seems, because most organisations do not have a single policy. They have a folder with an information security policy, an access control procedure, an acceptable use document and four things nobody has opened since 2023.
The second pass is the detailed one. Within each category, a more specific agent tests whether the policy meets the standard, at sub-requirement level. Not "does this document mention asset management" but "does this document describe the four things the standard says asset management must cover".
The frameworks are the ones Belgian organisations are actually measured against: CIS with its implementation groups one through three, CyFun 2023 and 2025 across basic, important and essential, and ISO 27001.
The difference between basic, important, and essential is not just a matter of wording or appearance, it has real meaning and consequences. Plenty of organisations that comfortably clear basic discover a substantial set of additional requirements the moment they need to meet important, which is the tier most NIS2 "important entities" in Belgium land on.
Asset management under CyFun Important: four things your policy should cover
Under CyFun Important, asset management carries six or seven sub-criteria. Open one of them, and the platform shows what the standard requires the policy to describe. In this case, four specific things.
The result:
Two of the four are fully covered and align with the standard
One is partially described, present in the policy but not fully meeting the requirement
One is not found at all
That single view does something a traditional review struggles with. It separates "we did not write this down" from "we wrote it down badly", and those two problems have different owners and different fixes.
The full analysis takes around an hour, depending on the volume and complexity of the documentation. Compared with the weeks a manual mapping exercise consumes, the gain is not the hour. It is that you can afford to run it again next month.
Why "partially covered" is the most useful answer
A tick or a cross tells you the verdict. It does not tell you what to do on Monday.
Partially covered is the verdict that carries instructions, provided the platform shows its reasoning. And that is the part worth insisting on.
Click into a partial result and you get three layers. First, what the standard is actually looking for, with the sub-requirements spelled out. Second, the AI reasoning: this and this were found in your policy, but these specific elements that the standard requires are absent. Third, the snippet view, showing the exact paragraph the analysis read.
"This is the exact paragraph it read."
That third layer is what separates an analysis from a black box. If a tool tells you a requirement is partially met and cannot show you which text it evaluated, you cannot verify the finding and you cannot act on it with confidence. You are back to trusting a score.
For a GRC team preparing an audit, the snippet view is also the fastest route to a defensible answer. When an auditor asks why a control is scored the way it is, you point at the paragraph.
Rewrite, re-upload, watch the score move
The loop closes here, and this is where a policy review stops being a project.
You take the reasoning, rewrite the section that fell short, and upload the revised document. The analysis runs again and the score reflects the change. Not next quarter, not at the next review cycle. Now.
That changes the economics of policy work. When a review costs three weeks of someone's time, you run it once a year and you write defensively, trying to cover everything in one attempt. When it costs an hour of processing, you can iterate: fix the weakest domain, re-run, fix the next one.
It also changes who can do it. The reasoning output is specific enough that the person who owns a domain can improve their own section without waiting for a consultant to interpret the framework for them.
From paper compliance to demonstrable alignment
The gap between what you wrote and what runs is not a documentation problem, and it is not a technical problem. It sits precisely between the two, which is why it belongs to neither team and tends to go unmeasured.
Cyfora analyses both sides and compares them. Your policy documents against the standard, your technology against best practice, and both against each other. What comes out is not a certificate. It is a list of where policy and reality have drifted apart, with the reasoning attached so your team can close the distance.
Want to know where your own documentation stands?
