Most of the work in this field is not the assessment. It is keeping the assessment true afterwards: evidence that expires, exceptions that lapse, reviews that come due, reporting deadlines that run in hours rather than weeks. This is built to carry that, and to keep the provenance of every figure while it does.
It does not do the work. It keeps the work from falling over.
Built around the NIS2 Directive and CyberFundamentals: Basic, Important, Essential. GDPR-aware throughout.
Below 80% assessed, no pass or fail is issued.
0 / 133 scored · bar 3.0
Key measure · scored in Ad Hoc review, 26 Aug 2026
Illustrative: synthetic tenant
A control set, a risk register, an asset inventory, a supplier list and a pile of evidence can all live in separate files. What cannot live there is the passage of time. Every one of those facts has a date on it: the date the evidence stops being current, the date the exception runs out, the date the control is due for review again. A file has no way of noticing when one of them passes.
That is the work that quietly rots between audits. Not the assessment: the upkeep afterwards.
Nine scheduled jobs run against every tenant. None of them are decorative. Each one exists because a date passes whether or not anyone is looking at it.
A task can carry a recurrence, weekly through to annually. When it is completed, the next occurrence is created with its due date advanced from the original due date, not from the day it was finished. Close a quarterly task three weeks late and the next one is still due on the quarter. The cadence does not drift into “late plus three months” the way a copied row does. The chain is linked, so an occurrence cannot be spawned twice.
Evidence carries an expiry date, and reads as current, expiring soon or expired, and it is the same status everywhere it appears: on the item, in the weekly reminder mail, and in the portfolio rollup. A control does not go on being compliant on the strength of a document that lapsed eight months ago without anybody being told.
An approved exception with an end date flips to expired on the day it passes. A daily sweep maintains the status, rather than every screen re-deriving expiry from a date comparison and slowly disagreeing about it. An exception with no end date is left alone on purpose. It is not expired, it is incomplete, and inventing a lapse for it would be fabricating a policy decision nobody made.
NIS2 Article 23 reporting is tracked per incident against the real clock: an early warning within 24 hours of becoming aware, full notification within 72, then the final report. Reminders run every three hours, because a daily job is useless against a 24-hour obligation.
A risk links to the controls that mitigate it, the assets and suppliers it runs through, and the information it puts at stake. An incident links to the assets, suppliers, risks and controls it touched, and to its own timeline of events with evidence attached to them. A policy links to the controls it covers, so coverage maps itself. A processing activity links to its suppliers and its information assets. These are relations, not text typed into three lists that have no way to disagree out loud.
A system is as sensitive as the most sensitive information it holds, and a server is as critical as the most critical process depending on it. Both are computed and shown, and neither is written back. The rating a person gave stays exactly as they set it, with the derived value beside it. A server rated medium carrying a process rated critical gets pointed out, not silently corrected. Overwriting a human judgement with a computed one would destroy the thing an assessor asks about first: who decided this, and why.
A control requirement reads like framework text. An engineer needs tick-points. A control's checklist can be drafted from its requirement and the evidence an auditor would look for, scope-limited to that one control, and the draft is never saved as it comes out. A person trims it and confirms it before anything exists.
Overdue actions chased daily. Certificates flagged before they lapse. A weekly digest per tenant. A posture trend captured weekly: explicitly an operational trend, mutable and not evidence, kept separate from the signed-off snapshots that are.
All of that upkeep is only worth something if the figure at the end can be defended. A verification body does not ask for the percentage on your dashboard. It asks what was observed, by whom, on what date, and what was only stated.
Scored in the Ad Hoc review of 26 Aug 2026, approved by the risk owner, who did not open the cycle.
That last line is the point. Most tooling cannot print it, because the number was never attached to a decision in the first place.
Platform administration sees counts: licences, customers, users, controls in the library. It sees no customer content. Reaching a tenant takes a request with a stated reason, an approval from the customer's side, a time limit measured in hours, and a line in the log.
Three things go further than that grant.
This is the question every regulated client eventually asks a supplier. The answer here is in the authorization layer rather than in a contract clause.
Run the intake. Scope and assurance level are worked out from sector, size and annex, and the reasoning behind the outcome is kept alongside it.
Work the controls in a review cycle. Score both axes, attach evidence, record exceptions where a requirement genuinely cannot be met.
Close the review as an immutable snapshot and export the evidence pack, with the trail from control to finding to evidence intact.
Each of these exists because one of the rules above needed somewhere to live.
A guided intake works out whether an entity falls in scope and at which obligation level, then assigns the matching CyFun profile. The inputs are kept, and so are both verdicts: what the rules suggested, and what a person overrode it to, with their reason and their name on it.
Documentation and implementation are scored separately per control, against the bar the assurance level demands: 2.5 at Basic, 3.0 at Important, 3.5 at Essential. Key measures are tracked individually, because one of them under the line fails the profile however good the average is.
Common scenarios come pre-filled with threat, vulnerability and outcome, and map themselves to the controls that mitigate them. Risks are written as scenarios rather than as missing measures, so a treated risk stays on the register instead of disappearing.
Information asset, supporting asset and supplier are linked as a real chain rather than as text in three separate lists. Sensitivity and criticality travel up that chain and are shown next to what a person entered, never written over it. A rating that contradicts what it carries gets pointed out, not silently corrected.
Policies are rendered from templates and link back to the controls they cover, so coverage maps itself rather than being cross-referenced by hand. Approval stays where it belongs: with the organisation, not with the tool.
Scoring runs through review cycles, and closing one freezes it: a closed cycle refuses every change, scores and evidence counts and exceptions alike. Last year's picture cannot quietly improve. Roles are enforced rather than suggested: whoever implements a control does not score it, whoever scores it does not close the cycle, and whoever opens a cycle does not approve it.
ISO 27001 as a lens, not a second framework. Annex A is shown as a read-only derivation over the CyberFundamentals work already done. Turning it on assigns zero new controls, and there is no scaled “ISO percentage”. The headline is coverage and gaps, and every figure drills through to the CyFun controls behind it. A control mapped to Annex A but above the customer's tier is shown as outside scope, never as a task.
Built and maintained by one person. Not commercially available: no demos, trials or sign-ups.
It is not a conformity assessment tool. Verification against the CyberFundamentals framework is performed by accredited bodies under national accreditation supervision, and nothing here substitutes for that judgement.
Technical questions about any of the mechanisms above, or how they are enforced, are welcome at info@nisaware.com.