Control System Assurance
Assurance for control systems specifically: control narratives, configuration and parameter sets, alarms and interlocks, recipes, interfaces, testing, and holding the controlled state after go-live. Control systems are where a small configuration change has an immediate physical consequence, and where the change can be made by an engineer whose role is not framed as making regulated changes. The validated state here erodes through routine engineering work rather than through projects.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 22 LINKSA control system is the one place where a small configuration change has an immediate physical consequence — and where the person able to make it is often in a role nobody framed as regulated.
06 · QUALITY MATURITY — CONTROL SYSTEM ASSURANCE, REACTIVE TO ADAPTIVE
Setpoints, alarms and interlocks are adjusted by engineering as operational work. The configuration is not a controlled artefact and no record of its state exists.
Changes go through a request process, but the process was written for applications and does not distinguish a display change from an interlock change.
The configuration is a controlled artefact with a known baseline, changes are classified by physical consequence, and a control narrative states what the system is supposed to do.
Deviation from baseline is detected rather than reported, and alarm and interlock changes are trended for what they say about the process underneath.
The system’s behaviour is specified, verified and monitored as a whole, so an engineer cannot make a consequential change without the quality system knowing.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 5 regulatory bodies: FDA, EMA, ISPE, ASTM, IEC.
RECORDS & OBJECTIVE EVIDENCE
- The controlled configuration baseline, with a record of the current state
- A control narrative stating intended behaviour, interlocks and alarm responses
- Change records classified by physical consequence, not by technical size
- Access records showing who can alter setpoints, alarms and interlocks
- Verification evidence for changes affecting a critical parameter
COMMON INSPECTION FINDINGS
- Setpoint or interlock changes made under maintenance rather than change control
- No baseline, so nobody can say whether the running configuration is the approved one
- Alarm limits altered to reduce nuisance alarms without assessing what they were protecting
- Engineering accounts with unrestricted configuration rights and no review of their use
- No control narrative, so intended behaviour exists only in the configuration itself
The configuration is the regulated artefact
For a configurable control system, the software is the vendor’s and the configuration is the organisation’s — the recipes, phase logic, parameter sets, alarm limits, interlock conditions and interface mappings. That configuration determines what the system does to product, so it is the object assurance has to control, and it is the object that changes most often.
GAMP 5 makes this explicit through its software categories: a configurable package is validated around its configuration and any custom code, not by re-testing the vendor’s standard functionality. The practical failure is a validation package that thoroughly tests standard functions and treats the site-specific configuration — the part nobody else has ever run — as a settings list to be documented.
The change route nobody framed as regulated
Control-system changes arrive through engineering, not through change control. An alarm limit adjusted to stop nuisance trips, a timer extended because a step was marginal, a parameter tuned during a campaign — each is made by a competent engineer solving a real problem, and each may alter what the system does to product. Where the engineering work-management route does not intersect the quality change-control route, the validated state degrades continuously and invisibly.
The control is not to make engineers raise change controls for everything, which fails within weeks. It is a defined classification, agreed in advance, of which control-system changes are GxP-relevant and must route through change control, with the boundary drawn in terms an engineer can apply at the point of work — parameter classes, alarm categories, recipe elements — rather than by asking each time whether something might be regulated.
Control narratives are the missing document
Sites hold the configuration and rarely hold the reasoning. A control narrative states what the system does and why: why the interlock trips at that value, which requirement the sequence satisfies, what the alarm is protecting. Without it, an engineer assessing a proposed change cannot tell which behaviours are deliberate, so the assessment defaults to whether the change works rather than whether it is safe to make.
This is also what makes periodic review possible. Reviewing a configuration against a narrative is a real check; reviewing it against nothing is reading a settings list and confirming it is still there. The narratives are cheap to write during the project and expensive to reconstruct afterwards, which is why they are almost always missing on older systems.
SPEQ interpretation — Part 11 obligations land on control systems too
Electronic-records requirements are associated with laboratory and quality systems, and control systems are frequently assessed as engineering assets instead. But where a control system creates or maintains GxP records — batch data, alarm history, operator actions, parameter changes — the access management, audit-trail and authority-check obligations of 21 CFR Part 11 and Annex 11 clause 12 apply exactly as they would to a LIMS.
This is where the practical gaps sit: shared engineering accounts on an HMI, audit trails not enabled because the vendor ships them off, and system clocks that are not synchronised, which quietly undermines the sequencing of every record the system produces. Each of those would be an obvious finding on a laboratory system and passes unremarked on a control system, because nobody framed it as a records question.
FREQUENTLY ASKED
What should be validated on a configurable control system?
The configuration and any custom code — recipes, phase logic, parameter sets, alarm limits, interlocks, interface mappings — rather than the vendor’s standard functionality. GAMP 5’s software categories make this explicit. The common failure is a package that tests standard functions thoroughly and documents the site-specific configuration as a settings list.
How do you stop routine engineering eroding the validated state?
By classifying in advance which control-system changes are GxP-relevant, in terms an engineer can apply at the point of work — parameter classes, alarm categories, recipe elements. Requiring a change control for everything fails within weeks; requiring judgement each time produces inconsistent judgement.
What is a control narrative and why does it matter?
A statement of what the system does and why: why the interlock trips at that value, which requirement the sequence satisfies, what the alarm protects. Without it an engineer assessing a change cannot tell which behaviours are deliberate, and periodic review degrades into confirming a settings list is still present.
Does 21 CFR Part 11 apply to control systems?
Where the system creates or maintains GxP records — batch data, alarm history, operator actions, parameter changes — yes, with the same access-management, audit-trail and authority-check obligations as any other system. Shared engineering accounts, disabled audit trails and unsynchronised clocks would be obvious findings on a LIMS and routinely pass unremarked here.