Unknown is a result. Hiding it is the problem.

Give the claim a boundary

Statements such as “the environment is resilient” are difficult to check. They leave too much unanswered: which service, against which failure, under what conditions and for how long?

A narrower claim is more useful. For example: the dispatch service can recover within its agreed interruption window using the documented recovery arrangement.

Now the team can ask what evidence would support that statement. A completed backup job helps, but the service may also depend on identity, network access, application compatibility and an operator who can follow the procedure.

When one of those dependencies remains untested, the gap belongs in the conclusion.

Ask four questions of the evidence

First, where did it come from? A machine observation, a provider diagram and a site operator’s account can all be useful. Keep the source clear so another person can understand its strengths and limits.

Second, when was it true? Collection time and the period covered are not always the same. A recently received document may describe an old configuration. Set a review interval appropriate to how quickly the environment changes.

Third, what does it cover? Be specific about the service, site, assets and operating conditions. Evidence from a lab or a partial test may answer an important question while leaving the wider claim unproven.

Fourth, does anything disagree? A diagram, a configuration record and a site observation can tell different stories. Keep the contradiction visible until it is resolved or explicitly accepted as a limitation.

Make uncertainty actionable

“Unknown” becomes useful when it names the next check. “The two carrier routes have not been physically verified” gives the owner a specific evidence gap. “Low confidence” on its own does not.

Record why the gap matters, who can resolve it and what the verification would involve. The team can then compare the value of that work with the other demands on its time.

Sometimes the available evidence will remain incomplete. The owner can still make a decision, provided the uncertainty and its possible consequence are explicit. Record the decision, its rationale and the conditions that should trigger a review.

Carry the same discipline into change

Evidence informs a recommendation. Action needs its own authority and operating conditions.

Before collection, testing or change, confirm the responsible owners, agreed method, stop conditions and recovery arrangements. Where the infrastructure supports an operational or safety-related process, involve the appropriate site and domain specialists.

NIST’s operational technology security guidance recognises performance, reliability and safety requirements as part of the environment. The implication for delivery is practical: the method must fit the operation being protected.

After an authorised action, collect fresh evidence and check the agreed result. Preserve the remaining gaps. A well-presented report is helpful; a conclusion that can be traced, challenged and verified is what makes the work dependable.