This is a ready-to-use risk assessment for a control system that is properly validated today but is aging out of vendor support. It is a different problem from an unvalidated legacy system (see the legacy system classification and remediation risk assessment for that case): here the control logic is fine, and the risk is that the platform underneath it is going away. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through document control. A worked filled specimen follows the template. This is general guidance to adapt and verify, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Control System Obsolescence and Migration Risk Assessment |
| Document number | <<FILL: ID, e.g. RA-AUTO-009-01>> |
| Version | <<FILL: version>> |
| Assessment date | <<FILL: date>> |
| System assessed | <<FILL: SYSTEM NAME / ID, e.g. fermentation DCS, Line 3 filler PLC>> |
| Assessment owner | <<FILL: role, e.g. Automation Engineering Lead>> |
| Next scheduled review | <<FILL: date, at least annual or on new vendor notice>> |
1. Purpose and methodology
This assessment captures the obsolescence exposure of a specific control system asset and sets its disposition: replace in kind, re-platform, or accept the residual risk with compensating controls and a defined review date. It is scored across four dimensions rather than the usual severity/probability/detectability model, because the driving risk here is external (a vendor decision), not internal process failure. The method is risk-based in the spirit of ICH Q9 and assumes the system’s validated logic is sound; it is the platform carrying that logic that is under assessment.
Assessment team: <<FILL: names and roles: automation engineering, CSV, QA, IT/OT security>>.
2. Asset description
| Field | Entry |
|---|---|
| System / platform | <<FILL>> |
| Vendor | <<FILL>> |
| Hardware / software version in use | <<FILL>> |
| GxP process supported | <<FILL>> |
| Date installed / last requalified | <<FILL>> |
| Current validated state confirmed | Yes / No, <<FILL: reference to last periodic review>> |
3. Obsolescence risk scoring
Score each dimension 1 (low exposure) to 5 (high exposure). The overall exposure is the highest single score, not an average; one dimension at 5 drives the disposition regardless of how the others score.
| Dimension | Score 1 | Score 3 | Score 5 |
|---|---|---|---|
| Vendor support status | Current generation, full support, multi-year roadmap confirmed | Mature product, standard support, no stated end date yet | Discontinued, in extended support only, or a stated end-of-support date within the planning horizon |
| Spare parts availability | OEM stock readily available | OEM stock limited, lead times extended | OEM no longer manufactures the part; sourcing is secondhand or gray-market only |
| Cybersecurity patchability | Vendor issues regular security patches | Patches issued infrequently or with a lag | Platform can no longer receive security patches at all |
| Data accessibility risk | Current software reads all historical data natively | Reading older data needs a specific legacy version kept available | No supported way remains to read historical data without a migration |
| Dimension | Score (1-5) | Evidence |
|---|---|---|
| Vendor support status | <<FILL>> | <<FILL: vendor notice, roadmap communication, date>> |
| Spare parts availability | <<FILL>> | <<FILL: stores inventory, sourcing records>> |
| Cybersecurity patchability | <<FILL>> | <<FILL: last patch date, vendor statement>> |
| Data accessibility risk | <<FILL>> | <<FILL>> |
Overall exposure (highest single dimension): <<FILL>>.
4. Disposition decision
Work the questions in this order; it resolves the decision fastest and keeps the rationale defensible.
| Question | Answer | Resulting path |
|---|---|---|
| Can the same function be replaced in kind (same vendor or platform, current-generation hardware and software)? | <<FILL: Yes / No>> | Yes: replace in kind, requalify the changed component against the existing control strategy |
| If not in kind, can the platform be re-platformed to a current architecture within an acceptable timeframe and budget? | <<FILL: Yes / No>> | Yes: re-platform, scoped and qualified like a new system |
| If neither is feasible now, can the residual risk be managed with compensating controls for a defined interim period? | <<FILL: Yes / No>> | Yes: risk-accept with compensating controls and a QA-approved review date; No: escalate for capital/timeline exception |
Disposition selected: <<FILL: replace in kind / re-platform / risk-accept with compensating controls>>. Rationale: <<FILL: two or three sentences tying the scoring to the decision>>.
5. Compensating controls (if risk-accept is selected)
| Control | Detail |
|---|---|
| Additional network segmentation | <<FILL: e.g. restrict the zone to read-only historian traffic>> |
| Enhanced monitoring | <<FILL: e.g. alert on any new connection attempt to the asset>> |
| Spares strategy | <<FILL: e.g. secure remaining OEM stock, define firmware verification for any secondhand part>> |
| Review interval | <<FILL: e.g. every 6 months until disposition changes>> |
| Accountable owner for the interim period | <<FILL: name / role>> |
6. Migration qualification scope (if replace in kind or re-platform is selected)
| Activity | Scope |
|---|---|
| Logic equivalence verification | <<FILL: side-by-side comparison of old and new logic, or a parallel run, where the process allows it>> |
| Historical data migration | <<FILL: method, and verification that migrated data retains its original meaning and true-copy status>> |
| Requalification depth | <<FILL: full IQ/OQ/PQ as for a new installation, referencing the OQ protocol at /templates/protocol-automation-oq-plc-scada-dcs>> |
| Target completion | <<FILL: date, tied to capital planning cycle>> |
7. Acceptance criteria
This assessment is complete and ready to act on when all of the following are true:
- Every scoring dimension has documented evidence, not an unsupported estimate.
- A disposition is selected and the rationale is traceable to the scores.
- If risk-accept was chosen, compensating controls, a review date, and an accountable owner are named, not left open-ended.
- If replace in kind or re-platform was chosen, the migration qualification scope is defined and tied to a target date.
- QA has reviewed and approved the disposition.
8. References
MHRA “GXP” Data Integrity Guidance and Definitions, Revision 1 (March 2018): legacy system provisions, including the expectation that facilities with industrial automation and control equipment such as programmable logic controllers can show progress toward upgrades providing individual login and audit trails. ICH Q9(R1), Quality Risk Management. EU GMP Annex 11, Computerised systems, and Annex 15, Qualification and validation. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022). IEC 62443 series, Security for industrial automation and control systems, for the cybersecurity-patchability dimension.
Confirm the current version and clause numbers of each reference before issue.
9. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessment owner (Automation Engineering) | <<FILL>> | ||
| CSV / Quality representative | <<FILL>> | ||
| Quality Assurance approval | <<FILL>> |
Filled specimen
Illustrative, for a fermentation DCS three years past the vendor’s extended-support date.
Asset: Fermentation DCS, Building 2, vendor platform version <<illustrative>>, installed 2016, last periodic review confirmed validated state current.
Scoring:
| Dimension | Score | Evidence |
|---|---|---|
| Vendor support status | 5 | Vendor notice confirms extended support ended 3 years ago, no further patches planned |
| Spare parts availability | 3 | 18 months of spare controller stock on hand, sourced from OEM before discontinuation |
| Cybersecurity patchability | 5 | Operating system can no longer receive vendor security patches |
| Data accessibility risk | 2 | Current historian client still reads all historical data natively |
Overall exposure: 5 (vendor support and cybersecurity patchability both at the ceiling).
Disposition decision: Replace in kind was not available (platform discontinued). Re-platforming within the current capital cycle was assessed as feasible but not immediate. Disposition: risk-accept with compensating controls for the interim, re-platform scheduled for the next capital cycle.
Compensating controls: Added firewall rule restricting the DCS network zone to read-only historian traffic; monitoring added for any new connection attempt to the zone; remaining OEM spare stock secured and reserved for this line only; review interval set at 6 months; Site Quality Head named as accountable owner for the interim period.
Migration qualification scope (for the scheduled re-platform): Side-by-side logic comparison planned for the batch-management module; historical data migration to the new historian with a true-copy verification step; full IQ/OQ/PQ scoped as for a new DCS installation; target completion tied to the next annual capital plan.
That sequence, honest scoring that lands at the ceiling rather than being softened, a disposition with a named owner and a date rather than an open-ended acceptance, and a migration scope defined before the work starts, is what turns an obsolescence finding into a defensible risk-based decision instead of a liability sitting in a spreadsheet.
Common inspection findings this assessment prevents
- An obsolescence risk is known informally but never documented, scored, or given a disposition.
- A risk-accept decision with no review date, so an interim position quietly becomes permanent.
- Spare parts sourced secondhand with no verification that firmware or hardware revision matches the validated baseline before installation.
- A migration treated as a simple cutover with no logic-equivalence verification or requalification.
- Cybersecurity exposure from an unpatchable platform never assessed as a standing risk, only noticed after an incident.
How to adapt this assessment
- Set your document number and assign a real owner and review date in the header.
- Score the four dimensions from actual vendor communications and stores records, not estimates; attach the evidence.
- Follow the decision order in section 4 rather than jumping straight to a preferred outcome.
- If risk-accept is chosen, name a real accountable owner and a real review date; an assessment with neither is not something anyone can act on.
- Confirm every reference in section 8 against the current published version before issue.