Every tool that holds a risk register faces the same design question, usually within its first month: what happens when somebody tries to save an entry that is not finished?
The instinctive answer is to refuse. Mark the fields required, validate on save, and no incomplete risk ever enters the register. It looks like quality control. It is the fastest way to end up with a register full of confident nonsense.
What a required field actually produces
Picture the workshop. Fifteen people, ninety minutes, and about thirty risks that exist only as sentences on a whiteboard. Somebody has to get them into the system before the room empties and the wording is lost.
Now make likelihood and impact mandatory. The person typing has three options. They can stop and run a scoring discussion for each risk, which the meeting has no time for. They can keep the list in a side document and promise to enter it properly later — the promise that produces the fifth spreadsheet. Or they can put a 3 in both fields and move on.
Under time pressure, most people put a 3 in both fields. The register then contains thirty risks rated medium by nobody, with no marker distinguishing them from thirty risks rated medium after an argument. The validation did not create quality; it created data that looks like quality, which is strictly worse, because the missing value announced itself and the invented one does not.
The same mechanism runs through the whole model. Require a treatment strategy and you get Mitigate as the default answer, because it is the least committal word available. Require a justification and you get "see policy". Require a review date and you get one that nobody chose. A required field does not extract information that does not exist yet. It extracts a placeholder, and placeholders are indistinguishable from decisions three months later.
The order people work in is not the order the model describes
The model is clean: identify, analyse, evaluate, treat, monitor. Reality is not.
The title and the context arrive first, in the workshop, while the wording is fresh. The rating waits for the person who knows the numbers — often somebody who was not in the room. The strategy waits for the meeting where it is actually decided, and deciding it properly is the point of that meeting. The residual rating cannot precede the treatment, and the treatment cannot precede the budget conversation.
Every one of those pauses is correct risk management. A register that treats them as errors is not enforcing the process; it is refusing to hold the process while it happens.
So what should the tool do instead?
Save what was typed. Then say what does not add up — and keep saying it until it is settled.
That is a different mechanism from validation, and the difference is worth naming:
Validation asks whether a field is filled. Advisory checks ask whether two entries can both be true. In progress with no treatment. Accept with three open actions. A residual rating below the inherent one with no explanation of what earned the drop. None of these is a missing field; each is a contradiction that only exists once you read two fields together, which is exactly the reading nobody does at 4pm on a Friday.
Validation fires at the moment of writing, when the author already knows. Advisory checks belong to reading time — the review, the audit preparation, the moment somebody who did not write the entry has to trust it.
Validation produces a wall. Advisory checks produce a queue. A wall gets worked around. A queue gets worked through, provided somebody can see it.
Where a requirement is right: the transition, not the draft
Advisory does not mean that nothing may ever be required. It means the requirement belongs at a different moment.
Saving a draft is one thing; claiming the work is finished is another. When somebody explicitly marks a risk as reviewed, approved or closed, they are making a statement to everyone who reads the register afterwards — and a statement of that kind may fairly carry conditions. A review that records no conclusion is not a review. A closure while treatment actions are still running is a claim the register can check on the spot.
The line is worth stating plainly: accept incomplete work in progress, and hold the transitions that declare it complete. A tool that blocks the save collects placeholders. A tool that blocks nothing at all lets somebody close a risk that is demonstrably not settled. Both are avoidable, and the difference between them is which moment you put the rule at.
The failure mode of being advisory
Honesty about the trade: advice that nobody reads is decoration.
This is the real cost of choosing not to block, and it is the reason most tools take the shortcut. A hint on one risk page is invisible in a register of two hundred. The person who most needs to see it — whoever answers for the register as a whole — is precisely the person who does not open entries one at a time. If the check only ever appears where the data is written, it may as well not exist.
So the design is only complete with a second surface: the same rules, run across everything, in one list, in front of the person accountable for it. In EasyRisk.io that is a page called Quality, and the number sits on the dashboard where the register's owner already stands every morning. Nothing there blocks a save. The rules only make visible what was already true — which is the whole argument of this article, stated twice, because the second half is the one tools usually skip.
Two details that decide whether people trust it
Read the saved state, not the form. A check that reacts to every keystroke flickers exactly while somebody is fixing it, which is the most annoying moment available. It should describe the record as it stands.
Do not hand out instructions the reader cannot carry out. If somebody may only read a board, listing the corrections they cannot make is noise dressed as accountability. Show it to the person who can act, count the rest, and say that you did.
Frequently asked questions
Are required fields ever right? Yes, in two places. For the fields that make the record findable rather than complete — a title, and whatever your identifier scheme needs. And at the transitions where somebody declares the work finished. A judgment should rarely be mandatory while the entry is still a draft, because judgments have a schedule of their own.
Does advisory checking mean lower data quality? In practice, the opposite. The half-finished entry is visible as half-finished, and it goes on a list until it is settled. The alternative is a register where the placeholder and the decision look identical.
How do you stop the list of findings growing forever? By putting it where the register's owner reads it, and by keeping the rules few and mechanical enough that each finding names a fix. See the health check for the full set.
Is this specific to risk management? No, but risk registers make the case unusually clearly: the register's value is the reasoning behind the numbers, and reasoning cannot be produced on demand by a form validator. See choosing risk management software for the other questions worth asking a vendor.
A register is a working document maintained by busy people in an order the model does not anticipate. A tool that insists on completeness gets fiction. A tool that accepts what it is given and keeps pointing at the gaps gets a register that improves — slowly, visibly, and honestly.