Custom OT environment
If you do not look like any of the examples, that is the normal case.
Most industrial operators are a mixture: a modern line, a legacy corner nobody has replaced, a vendor-run skid, and shared site services that everything depends on. OTReady has no sector template to make you fit, because it does not have one at all.
- No fixed domain taxonomy: you name your own OT Domains
- No prescribed architecture: Sites, Zones, Subzones and Conduits are yours to define
- The same assessments, findings, remediation and reports as every other estate
- IEC 62443 and NIS2 on whatever the plant actually is
Understand the environment
The product has no opinion about what you are.
There is no sector selector that changes the model, no template that pre-fills your zones, and no list of domains you must map yourself onto. The canonical objects are the same everywhere, and what they are called is yours.
That matters most for the estates that do not resemble a textbook. A vendor-managed cell that the supplier administers entirely. Two pre-2005 machines reachable over a protocol with no authentication. Shared site services that half the plant depends on and nobody owns. Those are not edge cases to be worked around; they are objects, with targets, findings and evidence like anything else.
The starting point is usually smaller than people expect. One site, the zones you can describe today, the conduits between them, and an honest "not recorded" wherever that is the truth.
- Mixed vintages and mixed vendors inside one plant
- Systems operated by a supplier rather than by the operator
- Legacy equipment that cannot be patched and will not be replaced soon
- Shared services that cross every functional boundary
A domain is not a zone.
The single most useful distinction for an estate that fits no pattern, and the one most often collapsed.
Keeping them apart is what lets "everything in the Line 4 programme" and "everything inside the line control zone" be different questions with different answers, which in a mixed estate they almost always are.
Zone
Security architecture. It has a target, it is what a requirement is assessed against, and it defines a boundary. A zone is where a conclusion applies.
OT Domain
Functional context, in your words. Assigned many-to-many across zones, conduits, channels and assets. It confers nothing, defines no boundary, and is never a Security Level.
Your vocabulary
Domains named by the operator, not by the product.
OTReady ships no domain list. An operator names what it actually calls things, whether that is a programme, a shared service, a supplier arrangement or simply "the legacy estate", and assigns those names across the objects they apply to.
Renaming a domain later keeps its identity and every assignment it already carries, so the vocabulary can improve without the estate having to be rebuilt.
How OTReady applies
The same chain, on whatever you have.
- OT context
- Architecture
- Risk
- Targets
- Assessments
- Findings & Evidence
- Remediation
- Reports
An estate that starts blank goes through exactly these steps. Nothing is skipped and nothing is pre-filled on your behalf.
Conduit and channel
The supplier-run system, written down honestly.
A vendor-managed cell is the case where "we do not really know" is the accurate answer, and the model has to be able to say it. The monitoring session is encrypted, the data collection is not, and the supplier's control session is not recorded either way.
Three channels, three different answers, one conduit. The third one stays "not recorded" until somebody finds out, because promoting it to "fine" is how an estate acquires a position it cannot defend.
Assurance
A first pass, and it looks like a first pass.
An estate at the beginning does not read well, and it should not. The cockpit states each dimension with its reason and produces no score to average the difficulty away.
Representative use cases
What operators without a template bring to it.
- A first architecture
- One site, the zones that can be described today, and the conduits between them. Everything else follows from there.
- Supplier-operated systems
- Modelled as zones with their own targets, and with the access paths named rather than assumed.
- A legacy corner
- Equipment that cannot be patched, recorded as an object with a governed exception rather than left off the model.
- Your own programme structure
- Domains named after the programme, the service or the site, whichever is how the organisation actually talks.
What this page does and does not claim.
This is the generic platform capability, which is what every other sector page is also showing. There is no template here and none anywhere else. The screenshots come from an illustrative configuration built to render the application for this page; it is not a customer and not a demonstrated use case.
Where the detail lives
The platform
The whole chain, from OT architecture to issued reports.
OT Domains
Customer-defined functional context, and what it deliberately is not.
OT architecture
The canonical objects, and how an estate is built from them.
See OTReady against your own environment.
A working session on whatever your plant actually is, in your own vocabulary.