Asset and zone
What is being protected, and where the trust boundary runs. Zones and conduits are objects in their own right, not columns you invented.
Methodology
Trausto is not a vertical. The same engineering discipline carries across regulated industries; what changes between them is the standard you have to answer to. Those are built in as first-class methodologies, not as a template retro-fitted onto a generic risk register.
Derivation
A risk rating is defensible when someone else can retrace how it came about. This is the chain the product walks, in the order it walks it — including the one step that is set rather than derived today.
What is being protected, and where the trust boundary runs. Zones and conduits are objects in their own right, not columns you invented.
What happens if it fails — safety, availability, environment. Consequence comes first, because it is the part a plant engineer can judge without a security background.
Two named scales from 1 to 5. How reachable the zone is, and how much resistance it offers when reached.
Derived from those two, not estimated separately. The matrix below is the whole rule — there is nothing behind it.
Consequence and likelihood, before a single measure is credited. This is the number that shows what you are actually carrying.
What you put against it, and the document that proves it — mapped to FR1–FR7 so an assessor recognises the shape.
The same arithmetic once the measure counts. The difference between initial and residual is the effect of the measure, and it is the figure an audit asks for.
Today you set the security level target yourself and the model records who set it. Deriving it normatively from the assessment is in development. A set target is perfectly auditable as long as it is marked as set; an unmarked one is a finding.
Calibration
These are the shipped steps, not an illustration. They are what the two axes of the matrix mean.
And here is the honest limit: the steps carry names, not criteria. Two engineers can read "Extensive" differently, and no methodology settles that for you — it is settled by writing down, once, what your organisation means by each step and holding every assessment to it. That definition is yours to make. We would rather say so than let a named scale imply a calibration it does not provide.
Vulnerability ↓
| Vulnerability | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 5 | 3 | 4 | 4 | 5 | 5 |
| 4 | 3 | 3 | 4 | 4 | 5 |
| 3 | 2 | 3 | 3 | 4 | 4 |
| 2 | 2 | 2 | 3 | 3 | 4 |
| 1 | 1 | 2 | 2 | 3 | 3 |
Exposure →
The shipped matrix, rendered here from its own formula: the rounded-up mean of exposure and vulnerability. Exposure 4 and vulnerability 3 yield likelihood 4 of 5.
Governance
A method you can edit at will is not a method. This is what may change, what may not, and what happens when we update the base.
The system templates are platform records we curate and version. They are what a fresh project resolves to, and no organisation can edit them.
Display labels, descriptions, and your own additional fields. Everything you need to make the method speak your plant's language.
Scoring scales, the derivation formula, the risk bands, the thresholds, and the identity and order of the steps. A write that touches them is rejected at the write, not merged quietly at runtime.
An override records the base version it validated against, and a non-permitted change never reaches the effective configuration — it is rejected at the write, not merged quietly at runtime. The full upgrade flow — re-validating every override against a new base and quarantining what no longer fits, with a notice and an audit entry — is fixed in the architecture decision and due before general availability; today the write-side gate is what ships.
Register entries record the base version together with a hash of your overrides; projects and the report header record the base and mapping versions. So a later re-banding of the scales cannot masquerade as a change in risk posture — the series breaks, visibly, at the point the configuration changed.
Built in
Zones, conduits and trust boundaries are native objects, not custom columns in a GRC tool. SL-T targets sit on the zone, map to the FR1–FR7 of IEC 62443-3-3 and export as evidence an assessor will recognise. Deriving SL-T normatively from the assessment is in development — today you set the target and the model records who set it.
The information-security risk-management process end to end — context, identification, analysis, evaluation, treatment — running on the same asset and consequence model the 62443 work already uses. No second inventory to keep in sync.
An ISMS register with the Statement-of-Applicability mechanism: applicability decisions, the justification for each one and the evidence attached to it — built for the audit conversation rather than for a spreadsheet. The Annex A control catalogue itself is in preparation; ask us where it stands before you plan around it.
The railway adaptation of the 62443 method, selectable per project: rail step labels throughout, and likelihood derived from exposure and vulnerability. The 5×5 matrix behind that derivation ships as readable configuration, not as hidden code — you can check the arithmetic and disagree with it, which is the part an assessor actually asks about.
Stance
Sector labels sell well and survive no real assessment. A substation, a filling line and an interlocking differ in consequence and constraint, not in method. We would rather be exact about the standard you are audited against than list four industries and mean the same thing four times.
Zones & conduits · SL-T targets per zone · FR1–FR7 · Consequence-driven risk · Safety impact · Criticality · Statement of Applicability · Control evidence · Supplier evidence · Threat scenarios · Audit-ready exports.
Bring one real site — your zones, conduits and security level targets (SL-T). In a single technical session we show how Trausto turns it into audit-ready IEC 62443 evidence, with your assessment content encrypted before it ever leaves the browser.