Risk Assessment and Secure System Design

Learning objectives

• Structure a zone-and-conduit cyber risk assessment.
• Relate threat, vulnerability and consequence to tolerable risk.
• Explain the seven IEC 62443 foundational requirements.
• Derive an SL-T vector and cybersecurity requirements specification.
• Write requirements that can be verified.

Introduction

This module connects risk assessment with practical engineering decisions.

Main lesson

Risk assessment is the bridge to design

IEC 62443-3-2 structures security risk assessment for system design. IEC 62443-3-3 provides system security requirements and security levels. Used together, they create a traceable chain:

Essential function and consequence - credible threat path - zone or conduit risk - target security level - system requirement - design control - verification evidence - residual risk

If a control cannot be traced back to a requirement and risk, it may be unnecessary. If a significant risk cannot be traced forward to a verified control, the design is incomplete.

A practical assessment sequence

1. Define the SuC. Record function, boundary, dependencies, modes, assumptions and existing safeguards.
2. Perform initial risk screening. Identify the worst credible cyber consequences and areas needing detailed assessment.
3. Partition into zones and conduits. Group assets by function, consequence, trust and security need.
4. Assess each zone and conduit. Identify credible threat scenarios, vulnerabilities, existing controls and consequence.
5. Compare with tolerable risk. Use the asset owner's approved likelihood and consequence criteria.
6. Determine SL-T and additional requirements. Set the required strength for each foundational requirement.
7. Document the cybersecurity requirements specification. Allocate requirements and verification evidence.
8. Design, implement and validate. Confirm the integrated system meets the requirement.
9. Accept residual risk and maintain assumptions. Record accountable approval and review triggers.

Use risk equations carefully

Simple models often express:

Risk = likelihood x consequence

Some methods describe threat, vulnerability and consequence separately. Either can help structure thinking, but the numbers are not objective measurements. Avoid multiplying arbitrary scores and treating the result as precision.

For each scenario, state:

• Threat source and objective.
• Entry point and preconditions.
• Vulnerability or weakness.
• Sequence of actions.
• Affected asset and function.
• Existing independent controls.
• Detectability.
• Physical, safety, environmental and service consequence.
• Recovery capability.
• Uncertainty.

The seven foundational requirements

IEC 62443-3-3 groups system requirements into seven foundational requirements.

Confidentiality may receive a lower target than integrity or availability in some zones, but it must still be assessed. Credentials, logic, keys and sensitive process information often need protection even when the process data itself is not secret.

From security level to specific requirements

Security level alone does not state the design. The cybersecurity requirements specification, or CRS, should include:

• SuC and zone / conduit reference.
• Risk or design-basis reference.
• Requirement identifier.
• Clear “shall” statement.
• Responsible party.
• Applicable lifecycle stage.
• Assumptions and external dependencies.
• Verification method.
• Required evidence.
• Residual limitation.

Weak requirement:

The system shall have secure remote access.

Stronger requirement:

Remote interactive maintenance access to the process-control zone shall be disabled by default and enabled only for an approved work order. It shall use a named account, multi-factor authentication, a managed jump host, time-limited authorisation to named destination assets, and retained session and change records.

The stronger requirement is not complete until the project defines how each element will be tested.

Worked threat scenario: vendor remote access

Unacceptable outcome: Unauthorised PLC logic change causes pumps to operate outside hydraulic limits.

Path: Compromised vendor account - remote gateway - engineering workstation - PLC programming service.

Weaknesses: Permanent access, shared credential, unrestricted destination, no application control and no independent change alarm.

Existing protection: PLC logic permissives and independent protective shutdown.

Required treatment:

• Named identity and MFA.
• Disabled-by-default access.
• Approved session through a DMZ and jump host.
• Destination and service restriction.
• Managed engineering endpoint.
• PLC change logging and operator notification.
• Independent protective function.
• Verified backups and restoration.

Residual risk question: Can an authorised but malicious engineer still make a harmful change, and which independent controls limit that consequence?

Security requirements must be testable

Use several verification methods:

• Document and design review.
• Configuration inspection.
• Functional test.
• Negative test.
• Failure and degraded-mode test.
• Log and alarm review.
• Backup restoration.
• Traceability review.

Penetration testing can add evidence, but it does not replace requirements-based verification or process-safety validation.

Engineering example

Practical activity

Knowledge check

Key takeaways

Relevant standards and guidance

This module uses original explanatory language. Consult the applicable editions and project requirements rather than treating this lesson as normative text.

• ISA/IEC 62443-3-2
• ISA/IEC 62443-3-3

Further reading

• IEC 62443-3-2:2020 — Security risk assessment for system design
• IEC 62443-3-3:2013 — System security requirements and security levels
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
• MITRE ATT&CK for ICS

Last reviewed

15 July 2026.