Cybersecurity & Governance

Unknown is a status, not a pass

Missing, stale or failed evidence should reduce confidence visibly. An assurance system becomes dangerous when it converts what it could not observe into a healthy result.

Cybersecurity & Governance cyber assuranceevidence qualitydata provenancecoverage

In view

  • Pillar: Cybersecurity & Governance
  • Maturity: carefully framed publication
  • Edited for publication and safe disclosure.

Editorial note

Carefully framed
  • Some examples are deliberately abstracted to keep the judgement useful without exposing private systems, people, weaknesses or operational detail.
  • Product names, connector coverage, estate counts, control scores, unreadable assets, live evidence and employer-derived implementation detail.

The greenest dashboard in the room can be the least trustworthy if it hides the places it could not see.

That is a problem in monitoring, asset management, audit and cyber assurance alike.

A collector fails to reach a device. An API returns only part of the expected data. A connector does not support a feature. A report has not refreshed for several weeks. An asset sits outside the current scope.

If those conditions disappear from the result, the remaining data can look reassuringly complete.

It is not complete.

The correct status is unknown.

Missing evidence has different causes

Not all unknowns mean the same thing.

The source may be temporarily unavailable. Credentials may no longer permit collection. The platform may not expose the required information. The asset may have been deliberately excluded. The data may be present but stale. A parsing or normalisation error may have prevented the result from being understood.

Those causes need different responses.

A temporary collection failure might require an operational fix. Unsupported capability may require a manual control. An excluded asset may need a documented risk decision. Stale evidence may still have historical value but should not be presented as current truth.

Collapsing all of those states into a blank cell removes the information needed to act.

A useful assurance model names the evidence state

I prefer assurance systems that distinguish at least these conditions:

  • observed and within the expected state
  • observed and outside the expected state
  • stale
  • collection failed
  • unsupported
  • excluded by scope
  • inferred rather than directly observed That vocabulary may look less tidy than red, amber and green. It is more honest.

A red result tells the organisation that a problem was seen. An unknown result tells it that confidence is limited. Both can require attention, but they are not interchangeable.

Coverage needs a denominator

Percentage coverage is easy to misuse.

A dashboard may report that most assessed assets meet a control. That statement has little meaning unless the organisation also knows how many assets were expected, how many were successfully assessed and which categories were missing.

The same applies to identity, endpoint and cloud evidence.

A high success rate among the objects that answered is not the same as high assurance across the estate.

The denominator is part of the control.

If scope changes between runs, the trend needs to explain that. Otherwise the score can improve simply because difficult assets disappeared from observation.

Provenance comes before confidence

Every important result should be able to answer a few basic questions.

Where did the evidence come from?

When was it collected?

Which method produced it?

What scope was attempted?

What failed?

Was the conclusion directly observed or inferred from another fact?

Those details do not need to overwhelm the user interface. They do need to exist.

Without them, assurance becomes a collection of claims that cannot be challenged properly.

Collection failure is operational evidence

A failed collection is not merely a technical inconvenience around the report.

It may reveal something important about the operating environment.

Perhaps administrative access is inconsistent. Perhaps an asset is no longer managed. Perhaps a network path has changed. Perhaps the documentation is wrong. Perhaps the source platform itself is unhealthy.

The failure therefore belongs in the evidence model.

Hiding it to keep the report clean removes one of the most useful signals the process produced.

Unknown should reduce confidence, not create automatic failure

There is another balance to hold.

Unknown should not automatically be treated as proof that the control has failed. That would also overstate the evidence.

The correct response is to separate control condition from evidence confidence.

The system can say that the control could not be verified, explain why and require an owner to decide the next step. That is more precise than either green or red.

It also creates a route to improvement. Teams can fix the collection path, obtain manual evidence, accept a limitation or change the scope deliberately.

Why this matters beyond dashboards

This principle affects leadership decisions.

A risk report that hides unknowns can cause investment to move elsewhere. A compliance view can imply stronger assurance than exists. A project can be declared complete because the unresolved assets were not visible in the final count.

The problem is not cosmetic.

It changes what leaders believe.

The broader lesson

No alert is not proof of health when the system was never capable of observing the problem.

No finding is not proof of compliance when the collection failed.

No current data is not proof that the old state remains true.

Unknown is a legitimate evidence state, and mature assurance makes it visible.

Confidence does not come from making uncertainty disappear.

It comes from showing exactly where the evidence is strong, where it is weak and what the organisation intends to do about the difference.

About the publication

I turn complex infrastructure and cybersecurity responsibility into resilient services, controlled change and evidence leaders can trust.