Skip to content
Trausto

Methodology

Methodologies

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

From the plant to the evidence

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.

01

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.

02

Consequence

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.

03

Exposure and vulnerability

Two named scales from 1 to 5. How reachable the zone is, and how much resistance it offers when reached.

04

Likelihood

Derived from those two, not estimated separately. The matrix below is the whole rule — there is nothing behind it.

05

Initial risk

Consequence and likelihood, before a single measure is credited. This is the number that shows what you are actually carrying.

06

Measure and evidence

What you put against it, and the document that proves it — mapped to FR1–FR7 so an assessor recognises the shape.

07

Residual risk

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.

08

SL-T — set, not derived

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

The scale is named. The criteria are yours.

These are the shipped steps, not an illustration. They are what the two axes of the matrix mean.

Exposure
  1. 1 Isolated
  2. 2 Limited
  3. 3 Moderate
  4. 4 Extensive
  5. 5 Fully Exposed
Vulnerability
  1. 1 Hardened
  2. 2 Low
  3. 3 Moderate
  4. 4 High
  5. 5 Severe

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.

likelihoodDerivation · ceil((e + v) / 2) EN 50701

Vulnerability ↓

Likelihood derived from exposure and vulnerability
Vulnerability 12345
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

The methodology is governed, not free-form

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.

01

Curated and versioned

The system templates are platform records we curate and version. They are what a fresh project resolves to, and no organisation can edit them.

02

What you may override

Display labels, descriptions, and your own additional fields. Everything you need to make the method speak your plant's language.

03

What stays immutable

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.

04

What happens on an update

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.

05

Every result carries its pin

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

What sits in the product, not in a leaflet

01

IEC 62443-3-2 · Zones and conduits

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.

02

ISO/IEC 27005

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.

03

ISO/IEC 27001 · Annex A

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.

04

EN 50701

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

Why there are no industry pages

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.

See Trausto against your own zones

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.