Introduction to the IACS Cybersecurity Lifecycle
A practical introduction to managing industrial cyber security through the system lifecycle.
Learning objectives
- Describe security as a lifecycle rather than a design-stage activity.
- Identify the main assessment, implementation and maintenance activities.
- Assign evidence and acceptance points to each lifecycle stage.
- Explain how change triggers reassessment.
Introduction
This module introduces lifecycle thinking for industrial cyber security.
Planned video lesson
Video lesson coming soon. The written module can be completed without the video.
Planned recording: 7-9 minutes following one Riverside remote-access requirement from risk assessment through design, FAT, handover and periodic review.
Transcript will be added with the video.
Main lesson
Security has to survive the whole asset life
An IACS may operate for decades. During that time, staff change, vendors withdraw support, vulnerabilities are discovered, networks expand and the process is modified. A secure design that cannot be maintained or recovered will not remain secure.
A practical lifecycle is:
| Stage | Core questions | Typical evidence |
|---|---|---|
| Establish context | What function, system, consequence and obligation are in scope? | SuC definition, applicability register, asset-owner risk criteria |
| Assess risk | Which credible paths can cause unacceptable outcomes? | Threat scenarios, zone-and-conduit risk assessment, SL-T rationale |
| Specify | What must the organisation, system, service and product do? | Cybersecurity requirements specification, supplier schedules |
| Design | How will the requirements be met? | Architecture, data flows, account model, recovery design |
| Implement | Was the approved design configured correctly? | Build records, hardening checklists, configuration baselines |
| Verify and validate | Does the solution meet requirements in realistic conditions? | Reviews, FAT, SAT, test results, defect closure |
| Operate and maintain | Are access, vulnerabilities, backups and changes controlled? | Logs, patch records, access reviews, exercises, maintenance records |
| Decommission | Is access removed and sensitive information disposed of safely? | Account closure, media sanitisation, asset and drawing updates |
Treat evidence as a designed output
Security evidence should not be assembled after commissioning. The project should define:
- Evidence owner.
- Required format.
- Review and approval authority.
- Due stage.
- Configuration or asset version covered.
- Acceptance criteria.
- Retention and update requirement.
For example, “remote access shall use MFA” is incomplete unless the test method, logs, failure behaviour and accountable approver are also known.
Change is a lifecycle event
Reassessment may be required when:
- A new external connection is introduced.
- The process or safe state changes.
- A product reaches end of support.
- A major vulnerability affects an exposed asset.
- A new maintenance provider is appointed.
- The zone model or trust relationship changes.
- A temporary commissioning arrangement becomes permanent.
- Incident findings challenge an assumption.
Not every software update needs a full risk assessment. The change process should screen for security impact and escalate material changes.
Safety, operations and cyber lifecycle must meet
Cyber review points should align with engineering gates such as concept selection, design review, hazard review, factory acceptance, site acceptance, handover and management of change. This keeps cyber decisions attached to the physical system and avoids a separate late-stage checklist.
Planned original figure — M06-F01
Create a circular lifecycle showing context, assess, specify, design, implement, verify, operate, improve and decommission, with change feeding back into assessment.
Planned asset: /static/training/ot-cyber-security/module-06/figure-01.svg
Engineering example
Riverside application
Riverside must carry security evidence from concept and procurement through commissioning, operation, change and eventual decommissioning.
Practical activity
Apply what you learned
Choose five cyber deliverables and place them against project gates. Include at least:
- SuC and zone model before architecture approval.
- Cybersecurity requirements before supplier order.
- Configuration baseline before FAT.
- Restoration test before handover.
- Access and vulnerability review during operation.
Record your reasoning and project notes here. Your response stays in this browser and is not submitted to the website.
Loading saved response…
0 / 10,000Do not enter real credentials, confidential network details, sensitive asset information or security-sensitive project data.
Knowledge check
Answer every question correctly to complete this module. If an answer is incorrect, review the explanation and try again. This is not a formal examination.
Key takeaways
Remember these points
Cyber security must be planned and evidenced throughout the IACS lifecycle.
Changes in connectivity, consequence, support or suppliers can trigger a fresh cyber review.
Temporary commissioning access must be removed or converted into a governed operational path.
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-2-1
- ISA/IEC 62443-3-2
Further reading
- IEC 62443-2-1:2024 — Security program requirements for IACS asset owners
- IEC 62443-3-2:2020 — Security risk assessment for system design
- NCSC — Creating and maintaining a definitive view of your OT architecture
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
Last reviewed
15 July 2026.
Complete the knowledge check above and answer every question correctly to unlock module completion.
Progress is stored only in this browser and is not a certificate or formal training record.