Skip to content
OTReady

Findings & Evidence

One governed truth for security issues, and the evidence behind them.

Different sources raise issues in different ways. If each one keeps its own list, an operator ends up reconciling four registers by hand and an auditor is shown whichever one is tidiest. OTReady gives them one canonical Finding model instead.

  • One Finding identity, whatever raised it
  • A detection is not a Finding until it explicitly enters governance
  • Treatment is a recorded decision, not an implied next step
The OTReady governed Findings list, showing findings that have explicitly entered governance with the architecture object each one affects.
Governed Findings: explicitly entered into governance, each naming what it affects.

Canonical identity

Several sources, one model.

An assessment gap, a risk conclusion, an assurance condition and a promoted operational alert are four different ways of noticing the same class of problem. They converge on one Finding model with one identity, one provenance record and one lifecycle.

The alternative, a findings list per framework, produces silos that disagree, and makes "how many open issues do we have" a question with several defensible answers.

  • Assessment gaps, from IEC 62443-3-3 and NIS2
  • Risk conclusions from the detailed assessment
  • Assurance conditions
  • Operational observations, once explicitly promoted

A detection is not a Finding, and a recurrence is not a new one.

What the assessments currently detect is shown on the report and the remediation boards. A Finding exists because someone governed it. The same condition occurring again does not mint a second Finding, and a closed Finding does not silently reopen itself, because either would turn a register that people rely on into a stream nobody can count.

Treatment

Four decisions, and only one of them creates work.

Once a Finding is governed, someone has to say what is going to happen to it. That decision is recorded rather than inferred.

  1. Remediate
  2. Risk accept
  3. Not applicable
  4. Defer

Only Remediate creates remediation work. Accepting a risk, ruling something out of scope or deferring it are all legitimate outcomes, and each stays visible as a decision somebody made, rather than as an item that quietly disappeared from a list.

Attribution

A Finding names what it is about.

Attribution uses the canonical architecture, so a Finding points at an object rather than at a sentence describing one.

Site
Where the issue lives, when the whole location is the subject.
Zone / Subzone
The security scope the Finding concerns.
Conduit
The security relationship: the canonical subject where a Finding is about how two scopes are connected.
Communication Channel
Added attribution where the issue is about a specific communication inside a Conduit, rather than about the relationship itself.
Asset
Where the subject is an inventory object, and an asset is genuinely known.
Provenance
What raised it, and when it entered governance: carried with the Finding rather than reconstructed later.
The OTReady evidence register: a count of documents held by the project, and for each document the places that reference it.
The register lists every document the project holds and, beside each one, where it is used. On this demo estate these remediation records are not referenced anywhere else yet, and the page says so instead of leaving the field empty. The count is a count of documents, not coverage, and not a compliance result.

Evidence

One artifact, many contexts.

A document is one thing wherever it is used. A policy that supports a NIS2 control and also verifies a remediation task is not two uploads; it is one canonical evidence artifact with two contextual links.

What that document MEANS is answered separately in each context, because those are different judgements made by different people against different criteria. There is deliberately no global "approved" flag on an artifact: a file verified as sufficient for a remediation task would otherwise start reading as independently assured for a control it was never assessed against.

  • One artifact, one identity, one set of bytes
  • Contextual links to assessments, Findings, requirements and remediation work
  • Review outcomes belong to the context, not to the file

Where evidence is used

Evidence is contextual, not an attachment dump.

The same artifact can support an assessment conclusion, a Finding, a specific requirement, a risk decision, the verification of remediation work, or an issued report. Each of those links records its own review state.

That is what makes an evidence register worth reading. A folder of files proves that somebody uploaded things; a set of contextual links proves what each one was offered for and what was concluded about it there.

Related capabilities

  • Remediation

    What happens after a Finding is marked for remediation.

    Remediation

  • Assurance

    How Findings feed the derived reading of a project.

    Assurance

  • Reports

    Where Findings and evidence end up in an issued record.

    Reports

See one register instead of four.

Bring the lists you reconcile by hand today and see what one canonical model does to them.

Request a demoOTReady