This is a ready-to-use functional risk assessment for a control system. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal quality risk management process. A worked filled specimen follows the blank table. Verify each cited reference against the current source before you rely on it.
The purpose of a functional risk assessment is to decide, function by function, where the validation effort goes. You do not test everything equally; you concentrate on the functions that affect product quality, patient safety, and data integrity. This document scores each critical function so the qualification scope, the test depth, and the required controls follow the risk, in keeping with quality risk management under ICH Q9(R1) and the risk-based approach of GAMP 5.
Document control header
| Field | Entry |
|---|---|
| Document title | Control System Functional Risk Assessment |
| Document number | <<FILL: DOC-ID, e.g. QP-AUT-030>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| System | <<FILL: SYSTEM NAME / ID, e.g. Bioreactor skid DCS>> |
| GAMP category (assessed) | <<FILL: e.g. 4 configured with some Category 5 custom logic>> |
| Document owner | <<FILL: role, e.g. Validation / CSV Lead>> |
1. Methodology
This assessment uses a failure mode and effects analysis (FMEA). For each critical system function, the team identifies how it could fail, the effect of that failure on product, patient, or data, the likely cause, and the existing detection or control. Each failure mode is scored for Severity, Occurrence, and Detection on the scales below; the product gives a risk priority number (RPN) that ranks where attention is needed. High-risk items receive additional controls, and the residual risk after those controls is recorded.
The functions considered for a control system are, at minimum: critical interlocks and permissives, critical control loops, critical alarms, access control, the audit trail, the historian and batch record interface, time control, and backup and restore. Add functions specific to the process.
2. Scoring scales
Severity (S): the impact if the failure reaches product, patient, or the GMP record.
| Score | Severity | Meaning |
|---|---|---|
| 5 | Critical | Direct patient safety impact, or an undetected data integrity breach affecting release |
| 4 | Major | Product quality impact likely to affect disposition |
| 3 | Moderate | Quality impact that in-process controls would likely catch |
| 2 | Minor | Limited impact, easily corrected |
| 1 | Negligible | No quality, safety, or data impact |
Occurrence (O): how likely the failure is, given the design.
| Score | Occurrence | Meaning |
|---|---|---|
| 5 | Frequent | Expected to occur without a specific control |
| 3 | Occasional | Could occur; some inherent resistance |
| 1 | Remote | Very unlikely given the design |
Detection (D): how likely the failure is caught before it causes harm (a higher score means harder to detect).
| Score | Detection | Meaning |
|---|---|---|
| 5 | Very hard | No routine means to detect the failure |
| 3 | Moderate | Detectable by review or monitoring |
| 1 | Easy | Immediately evident or automatically flagged |
RPN = S x O x D. Set your action threshold in section 3; a common default is that any RPN at or above <<FILL: threshold, e.g. 27>>, or any failure mode with Severity 5, requires additional risk reduction regardless of RPN.
3. Risk acceptance rule
- Any failure mode with Severity 5 requires a specific, verified control, even if the RPN is otherwise low.
- Any RPN at or above
<<FILL: threshold>>requires additional risk reduction and a re-scored residual risk. - Residual risks that cannot be reduced further are accepted only with a documented justification approved by QA.
4. The assessment (blank)
| ID | Function | Failure mode | Effect (product / patient / data) | Cause | Existing control | S | O | D | RPN | Additional control / test | Residual S/O/D | Residual RPN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
<<FILL: F1>> | <<FILL: Critical interlock: no agitation with door open>> | <<FILL: interlock fails to block>> | <<FILL: safety + product>> | <<FILL: logic error / bypass>> | <<FILL: FAT interlock test>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: OQ force-condition test, evidence>> | <<FILL>> | <<FILL>> |
<<FILL: F2>> | <<FILL: Audit trail on config changes>> | <<FILL: audit trail disabled by user>> | <<FILL: data integrity>> | <<FILL: admin rights too broad>> | <<FILL: role design>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: lock config, OQ test, periodic check>> | <<FILL>> | <<FILL>> |
5. Mitigations and residual risk summary
Summarize the additional controls introduced and confirm the residual risk is acceptable:
<<FILL: F1 mitigation and residual conclusion>><<FILL: F2 mitigation and residual conclusion>>
Overall conclusion: <<FILL: the validation scope and controls defined here reduce the identified risks to an acceptable level; any accepted residual risk is justified below>>.
6. Acceptance criteria
- Every critical control function is represented with at least one failure mode.
- Every Severity 5 failure mode has a specific, verifiable control mapped to a qualification test.
- Every failure mode above the action threshold has an additional control and a re-scored residual risk.
- The scope of the qualification protocol traces to the high-risk functions identified here.
- Accepted residual risks carry a documented, QA-approved justification.
7. References
ICH Q9(R1), Quality Risk Management (referenced by title; described, not reproduced). GAMP 5 Second Edition, ISPE, risk-based approach to GxP computerized systems (referenced by title). 21 CFR Part 11 and EU GMP Annex 11 for the data integrity functions assessed. IEC 61511 where safety instrumented functions are in scope (assessed separately from basic process control).
Confirm the current version and clause numbers of each reference before issue.
8. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
9. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / CSV) | <<FILL>> | ||
| Process / Automation SME | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
Filled specimen
The following shows three scored functions on an example bioreactor DCS, so you can see how the scoring drives the scope. The numbers are illustrative; replace them with your own.
| ID | Function | Failure mode | Effect | Cause | Existing control | S | O | D | RPN | Additional control / test | Residual S/O/D | Residual RPN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| F1 | Critical interlock: no agitation with vessel door open | Interlock does not block agitator start | Operator injury and product exposure | Logic error or a maintenance bypass left in place | Vendor FAT test of the interlock | 5 | 3 | 3 | 45 | OQ test forcing the door-open condition with screenshot evidence; bypass use put under change control and logged | 5 / 1 / 1 | 5 |
| F2 | Audit trail on configuration and recipe changes | Audit trail is disabled by a privileged user | Undetected change to a setpoint that affects release | Administrator rights granted too broadly | Standard role design | 5 | 3 | 5 | 75 | Audit trail configuration locked, admin rights segregated from operators, OQ test that a user cannot disable it, periodic configuration check | 5 / 1 / 1 | 5 |
| F3 | Historian logging of a critical temperature tag | Wide compression deadband discards a brief excursion | Reviewable trend is smoother than the real process | Deadband tuned for storage, not for the record | Default historian settings | 4 | 3 | 5 | 60 | Compression on the critical tag tightened to a justified deadband, verified in OQ against a known injected excursion | 4 / 1 / 2 | 8 |
In this example the audit trail failure mode scored highest (RPN 75, Severity 5), so it drove a specific set of controls: locking the configuration, segregating rights, an OQ test proving a user cannot disable it, and a periodic check. The interlock and the historian compression each crossed the action threshold too, so both gained a targeted OQ test and a design change, and all three residual risks came down to an acceptable level. The qualification protocol scope then traces directly back to these three functions.
Common inspection findings this assessment prevents
- Validation effort spread evenly with no risk basis, so critical functions get the same shallow testing as trivial ones.
- A Severity 5 data integrity function (a disable-able audit trail, a shared login) with no specific control mapped to a test.
- Interlocks and alarms “assessed” only on paper, never challenged by forcing the condition.
- No record of why a residual risk was accepted.
- The qualification scope and the risk assessment disagree, so the tests do not match the risks.
How to adapt this assessment
- Set your system, GAMP category, and action threshold in the header and section 3.
- Build the function list from your URS and functional specification, ensuring every critical interlock, loop, alarm, and data integrity function is represented.
- Run the scoring with a cross-functional team (process SME, automation, validation, QA), not one person.
- Map every high-risk item to a specific test in your OQ protocol so the scope traces to the risk.
- Re-open this assessment on any significant change to the logic, the process, or the risk, and re-score the affected functions.