Vulnerability & Patch Management Under Change Control
The difficulty in a regulated estate is not detection. Vulnerabilities are disclosed publicly and scanners find them; the difficulty is change, because patching a validated system requires assessment and testing before it can be applied. That structural delay is legitimate. What is not legitimate is letting it become indefinite deferral with no assessment, no compensating control and no review date — which is the state most estates drift into.
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 · 24 LINKSPatching a validated system is a change, and treating it as maintenance is how the validated state degrades quietly — but refusing to patch because it is a change is how the exposure accumulates instead.
06 · QUALITY MATURITY — VULNERABILITY & PATCH MANAGEMENT UNDER CHANGE CONTROL, REACTIVE TO ADAPTIVE
Patching happens on IT systems and stops at the GxP boundary, where change control is treated as a reason not to.
Patches are applied in an annual window, so the exposure period is set by the calendar rather than by the vulnerability.
Vulnerabilities are triaged on exploitability in this estate, deployment timing follows that triage, and the change route is proportionate rather than uniform.
Testing depth is scaled to what the patch touches, so a security fix does not wait behind a full requalification it did not need.
The estate is built to be patchable — redundancy, test environments, staged deployment — so currency is normal operation rather than a project.
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 4 regulatory bodies: EMA, FDA, ISO, IEC.
RECORDS & OBJECTIVE EVIDENCE
- The vulnerability intake source, and triage records with exploitability reasoning
- Patch deployment records with dates, showing the interval from disclosure
- The change route taken per patch class, and its justification
- Regression or verification testing scaled to what the patch affected
- Compensating controls where a patch cannot be applied, and their review
COMMON INSPECTION FINDINGS
- GxP systems excluded from patching entirely on the grounds that they are validated
- Patching on a fixed annual cycle regardless of what is disclosed in between
- Patches applied as maintenance with no change record or verification
- Unpatchable systems with compensating controls that were never reviewed again
- Triage on published severity alone, with no assessment of exposure in this estate
Triage on exploitability, not on score
A CVSS base score describes a vulnerability in the abstract, with no knowledge of whether the affected function is present and reachable in your deployment, what an attacker would need in order to reach it, or what harm would follow. Treating the score as the decision produces both failure modes at once: emergency changes to systems that were never exposed, and slow responses to a moderate-scored flaw sitting behind a listening port on a production network.
Useful triage adds three things the score cannot know: is the vulnerable component actually present and the code path reachable in this configuration; is the asset reachable from anywhere untrusted; and does the asset have GxP impact. That third question is what makes the triage regulated rather than generic, and it is why the asset register has to carry the GxP attribute alongside the technical one.
Patching a validated system is change control, not revalidation
Two anti-patterns dominate. The first is treating validation as a reason not to patch at all, which converts an assessable risk into an accumulating one. The second is treating every patch as a full revalidation, which makes the cadence so slow the queue never clears — and then produces the first anti-pattern by exhaustion.
The defensible middle is a patch policy agreed in advance: a standing assessment of which patch classes are low-impact and re-verified by a defined regression set, which require targeted requalification, and which are deferred with a documented compensating control. Agreeing that once turns each patch from a negotiation into an application of a rule, which is the only way the volume becomes manageable.
Deferral is a decision that has to be recorded
Some vulnerabilities genuinely cannot be remediated: the vendor has no patch, the supported version exists only as a control-system upgrade with its own qualification burden, or the system is out of support entirely. These are real constraints and the answer is containment — tighter segmentation, removal of the affected service, restricted access, additional monitoring.
What separates a managed estate from an exposed one is whether that deferral is recorded as a decision with a compensating control, an accepted residual risk and a review date, or simply happens. The unrecorded deferral is worse than the risk it carries, because nobody is tracking it, the compensating control is not verified, and the review never occurs. Both IEC 62443-2-1 and Annex A of ISO/IEC 27001 expect the recorded form.
Configuration is the other half
Patching addresses known defects in software. A large share of real compromises exploit configuration instead: default credentials, unnecessary services, permissive shares, legacy protocols left enabled. These do not appear in a vulnerability feed and are not fixed by a patch cycle, so an organisation measuring itself only on patch currency can be diligent and still exposed.
Configuration baselines per platform, with drift detection against them, are the counterpart control. In OT the baseline is also a qualification artefact — the configuration is part of the validated state — which means drift detection and change control are looking at the same thing from two directions and should share a record rather than maintain two.
SPEQ interpretation — measure the window, not the count
Vulnerability programmes report counts: open findings, findings closed, percentage patched. None of those describe exposure, because a hundred low-severity findings on isolated assets is a healthier position than three critical ones open for eight months on production-reachable GxP systems.
The measure that describes the actual risk is the age distribution of unremediated critical vulnerabilities on production-reachable assets with GxP impact, alongside the count of deferrals whose compensating control has not been verified since it was agreed. Both are harder to produce than a patch percentage, and both would change a decision — which is the test any metric should have to pass.
FREQUENTLY ASKED
Does every security patch on a validated system need revalidation?
No. It needs change control with a risk-based impact assessment, which is not the same thing. A patch policy agreed in advance — classifying patch types by impact and defining the verification each class needs — lets routine patches clear through a defined regression set and reserves targeted requalification for changes touching GxP-relevant function.
Is a CVSS score enough to prioritise remediation?
No. The score describes the vulnerability in the abstract. Prioritisation needs three things it cannot know: whether the vulnerable code path is present and reachable in this configuration, whether the asset is reachable from anywhere untrusted, and whether the asset has GxP impact. Those can move the priority in either direction.
What should happen when a vulnerability genuinely cannot be patched?
It becomes a recorded deferral with a documented compensating control — segmentation, service removal, restricted access, additional monitoring — an accepted residual risk and a review date. The unrecorded deferral is the actual problem: nobody tracks it, the compensating control is never verified, and the review never happens.
Why is configuration management part of vulnerability management?
Because a large share of real compromises exploit configuration rather than software defects — default credentials, unnecessary services, legacy protocols. Those never appear in a vulnerability feed, so an organisation measuring only patch currency can be fully patched and still exposed. Baselines with drift detection are the counterpart control, and in OT the baseline is also a qualification artefact.