The IEC 62443-3-2 risk assessment, run as a workflow.
Open a risk assessment in OTRISK and the tabs are the standard: ZCR 1 System under Consideration through ZCR 7 approval, exactly as IEC 62443-3-2 defines them. Your own risk matrix, your own network diagrams, your own tolerable risk. Methodology debates end, because the methodology is on screen.
Illustrative recreation of the workspace · demo data, no customer content.
The seven ZCRs, on screen
IEC 62443-3-2 structures the risk assessment as seven requirements, ZCR 1 through ZCR 7, each with a defined output. OTRISK runs them as gated tabs: one person submits, another accepts, and the next step opens. This is what each step asks, and what the screen gives you.
Identify the System under Consideration
Scope decides everything downstream, so it comes first. Describe the system and its environment, import the network diagram, and build the asset inventory with criticality per asset: safety, operational and business impact, lifecycle and patch status, access points. The deterministic diagram parser prefills what it can read with certainty and flags the rest. No AI guesswork on your plant data.
Field note: the Polish CHP breach ran on connections nobody drew →
Initial risk assessment
Score unmitigated risks on your organisation's own matrix and see them plotted on the heat map, worst case highlighted. This is the moment management sees the whole picture of one installation on one page. Generate the Initial Risk Assessment document directly from this step.
Partition the SuC into zones and conduits
Draw zones and conduits on the diagram, with the standard's own checks built in: separate business and IACS assets, separate safety systems, account for temporary connections, wireless and external networks. The partitioning isn't a drawing exercise; it's the structure the rest of the assessment hangs on.
Field note: five zone-partitioning mistakes we keep seeing →
Compare risk to tolerable risk
The standard's gate question: does the initial risk exceed what you tolerate? OTRISK computes the suggestion from your own scores and your own tolerance line. If the answer is no, you're done and documented. If yes, you proceed with exactly the zones that need it.
Detailed risk assessment
Per zone and conduit: threats from a curated library built on the ENISA taxonomy, vulnerabilities referenced to CWE and NIST, impact per consequence category, likelihood before and after existing countermeasures, and a security-level target (SL-T) derived from residual risk. Every number carries its rationale.
Document: the Cybersecurity Requirements Specification
The CRS is the work product the standard requires and integrators build against. OTRISK assembles it from what you already did: SuC context, zone and conduit characteristics, threat scenarios, SL-T per zone. A completeness check gates the step: no asset left unassigned, no zone without a target.
Approval
The asset owner approves or rejects with reasons, on the record: who, when, why. Rejection reopens exactly the steps that need rework. From here on, the assessment is a living document with a signature, not a PDF in a drawer.
Your matrix, not ours
Risk managers rightly distrust tools that impose a risk model. In OTRISK your organisation's matrix is configured once: impact levels, likelihood scale, consequence categories such as Safety & Health, Environment, Operations, Financial and Product Quality, tolerable-risk bands and the mapping to security-level targets. Every assessment freezes its own copy, so results stay comparable across years even when the matrix evolves.
Nobody accepts their own submission
Every ZCR step is submitted by one person and accepted by another; the platform enforces it. Every change of state carries a name, a timestamp and a comment, permanently. When the auditor asks "who reviewed the zone partitioning, and when", the answer is a click, not an archaeology project.
The artifacts
The workflow ends in two documents, and neither is written by hand. Both are assembled from the live assessment, so what they say is what the workspace holds.
Initial Risk Assessment (IRA)
Executive summary, the plotted risk matrix, the ranked risk register, scales and method, all generated from live data.
Cybersecurity Requirements Specification (CRS)
The mandatory IEC 62443-3-2 work product, with the approval status on the cover.
Both regenerate on demand. Your assessment ages; the documents don't. Request the sample IRA report →
Questions your team will ask
How long does a IEC 62443-3-2 risk assessment take in OTRISK?
Scope-dependent. The workflow is built so the initial risk assessment of a first System under Consideration is measured in weeks, not months, and re-assessments become review passes because nothing is rebuilt.
Do we need to have IEC 62443 expertise in-house?
The workflow encodes the method, which lowers the bar considerably, but risk decisions remain yours. If you want guidance, our OT security experts co-run the first assessment and train your team until it runs alone. If you work with an OT security consultancy, they can work inside your environment with their own accounts and roles. Onboarding & enablement →
Will our auditor or certification body accept the output?
The IRA and CRS follow the structure the standard prescribes, and every verdict in them is traceable to a person and a date. Auditors can be given their own access instead of an export.
What do you need from us to start?
A network drawing (any common format), a list of the people involved, and one system you care about. That's the first workshop.
Where does our data live?
On a dedicated application instance and database per client, hosted in the EU, behind role-based access and MFA. Details on the Security & architecture page.
See your own system in it.
Bring one installation in mind. In thirty minutes we show you which parts of OTRISK fit your situation and how the way of working looks. You leave with concrete next steps and pricing.