SOP: IT Change Management Interface for GxP Computerized Systems

This is a ready-to-use SOP for the seam itself, not for any one lane of traffic crossing it. It does not replace the Patch Management SOP, the Emergency Change Work Instruction, or the Change Control SOP for Validated Systems; it is the procedure that decides which of those governs a given IT or infrastructure change, and it closes the gap where an infrastructure team runs a change entirely inside its own ITIL tool with Quality never aware it happened. It pairs with the Configuration Management and Baseline Standard and the GxP-Impact Triage and Change Classification form. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> connects its IT service management change process, commonly run on an ITIL framework, to its GxP change control process, so that no infrastructure or IT-operations change reaches a validated GxP system without the assessment, testing, and approval a regulator expects, while routine IT change keeps moving at the pace IT operations needs. This procedure is deliberately narrow: it does not itself classify a patch, execute an emergency fix, or run an application-level impact assessment. It determines, for every change, which governing procedure applies, and it owns the accuracy of the mechanism, the CMDB GxP flag, that makes that determination reliable.

2. Scope

This procedure applies to every change raised in the organization’s IT service management or ITIL change process, regardless of the underlying technology, server, storage, network, database, virtualization, cloud platform, or container orchestration platform, and regardless of which team executes it. It applies at the point a change is raised, before execution, and continues through the point a change is confirmed closed under its governing procedure. It does not define patch classification (governed by <<FILL: patch management SOP-ID>>), emergency execution steps (governed by <<FILL: emergency change WI-ID>>), or application-level categorization and testing (governed by <<FILL: change control for validated systems SOP-ID>>). Out of scope: process and equipment change control on the manufacturing floor, governed by <<FILL: SOP-ID>>, and changes to systems confirmed non-GxP under <<FILL: GxP determination SOP-ID>>.

3. Definitions

• GxP-impact triage gate: the mandatory checkpoint every IT change request passes through to determine whether it touches a system, or the infrastructure of a system, in the validated GxP inventory.
• CMDB GxP flag: the attribute on a configuration item that states whether it is, or supports, a validated GxP system. The triage gate reads this flag; the flag’s accuracy is this procedure’s central dependency.
• One-process pattern: the ITIL change tool itself is configured so a change flagged GxP-relevant triggers mandatory additional fields (impact assessment, QA approval, regression reference) and routes to Quality inside the same record. There is one change record.
• Two-process pattern: IT runs its change in the ITIL tool; a GxP-relevant change also opens a linked validation change control record in the quality system, cross-referenced to the ITIL record. The GxP record gates go-live.
• Pre-approved (standard) change: a low-risk, repeatable, previously characterized change type authorized in advance and executed with a standing regression test and a documented rationale, without a fresh full change control each time.
• Normal change: a change requiring case-by-case review, a change control record, and testing scoped to the affected function.
• Major change: a change with high potential impact, a formal impact assessment, and likely revalidation activity.
• Emergency change: a change implemented before the full prospective process can complete, to restore service or security, governed by the emergency change work instruction and reviewed retrospectively.

4. Responsibilities

5. Procedure

5.1 Choose and document the connection pattern

Leadership selects, documents, and gets QA approval for exactly one of the two accepted patterns in section 3: the one-process pattern or the two-process pattern. State the choice here: <<FILL: One-process / Two-process, and the tool or system of record for each>>. A third pattern exists only by accident, IT makes the change under ITIL and Quality never sees it, and this procedure exists specifically to prevent it. If different parts of the organization use different patterns (for example, one pattern for on-premises infrastructure and another for a cloud platform), document each and state which systems fall under which.

5.2 Keep the CMDB GxP flag accurate

The triage gate in 5.3 is only as reliable as the flag it reads. The configuration manager reconciles the CMDB GxP flag against the validated system inventory (see the GxP computerized system inventory register) at least <<FILL: frequency, e.g. quarterly>>, and immediately whenever a new system is validated, retired, or reclassified. A system missing from the CMDB, or present but mis-flagged, is treated as a finding, logged, and corrected before the next reconciliation, not carried silently.

5.3 Raise the change and pass the triage gate

Every change request, regardless of source, passes the GxP-impact triage gate before scheduling: does it touch a system, or the infrastructure of a system, flagged GxP in the CMDB. Complete the GxP-Impact Triage and Change Classification form for every change; a “No” result is recorded, not skipped, so the population of screened changes is auditable. A “No” closes in the ITIL tool alone. A “Yes” continues to 5.4.

5.4 Classify and route

For a “Yes” result, classify the change as pre-approved, normal, major, or emergency using the decision criteria on the triage form, and route it to the procedure that governs that class:

Record the classification and its rationale on the triage form; do not implement before the governing procedure’s own approval gate is satisfied, except under the emergency path, which carries its own contemporaneous-recording rule.

5.5 Track the linkage through closure

Whichever connection pattern is in use, maintain a live cross-reference between the ITIL record and any linked GxP record until both are closed. Neither record closes independently: the ITIL record does not close until the governing GxP procedure confirms its own closure, and the GxP record references the ITIL change ID it originated from.

5.6 Reconcile at the defined cadence

At <<FILL: frequency, e.g. quarterly>>, and feeding the periodic review process, reconcile: the population of ITIL changes closed against GxP systems in the period, the corresponding GxP change control records, and the CMDB and configuration baseline state. Any ITIL-closed change against a GxP system with no corresponding GxP record is a finding, opened as a deviation per <<FILL: deviation SOP-ID>>, not corrected quietly.

6. Acceptance criteria

• Exactly one connection pattern is documented and approved by QA, with no undocumented third pattern in practice.
• The CMDB GxP flag is reconciled against the validated system inventory on a defined cadence, with mismatches logged and corrected.
• Every IT change request has a recorded triage outcome, including “No” results, so the screened population is auditable.
• Every “Yes” triage result carries a classification, a rationale, and a reference to the procedure it was routed to.
• No IT change record closes independently of its linked GxP record where one exists.
• Periodic reconciliation finds no GxP-system change with a closed ITIL record and no corresponding GxP change control record.

7. Records generated

• Connection-pattern decision and QA approval (section 5.1).
• CMDB-to-inventory reconciliation record (section 5.2).
• Completed GxP-Impact Triage and Change Classification forms, including “No” outcomes.
• Cross-reference log linking ITIL change IDs to GxP change control IDs.
• Periodic reconciliation record and any resulting deviations.

8. References

EU GMP Annex 11 (2011), clause 10 (controlled change) and clause 4.3 (up-to-date listing of relevant systems and their GMP functionality). A substantially expanded draft revision was issued for consultation on 7 July 2025; confirm the in-force version before issue. 21 CFR 211.68(a) and (b) (controls and changes by authorized personnel). 21 CFR 11.10(a) (validation to ensure accuracy, reliability, and consistent intended performance) and 11.10(k)(2) (revision and change control with an audit trail). GAMP 5 Second Edition (ISPE, 2022), operational-phase change and configuration management processes. PIC/S PI 011-3, Good Practices for Computerised Systems in Regulated GxP Environments.

Confirm the current version and clause numbers before issue.

9. Revision history

10. Approvals

Filled specimen

Illustrative connection and one change routed through it. Replace with your own.

Without the CMDB network-dependency relationship, this change would have looked like a pure security improvement with no GxP system named anywhere in the request, and it would have shipped through the ITIL side alone.

Common inspection findings this SOP prevents

• No documented connection pattern, so different teams handle the ITIL-to-GxP handoff inconsistently or not at all.
• A CMDB GxP flag that was never reconciled against the validated system inventory, so the triage gate routes on stale information.
• Triage performed only on changes someone happened to think of as GxP-relevant, with no record of the “No” population, so the screening itself cannot be audited.
• An ITIL change record closed with no corresponding GxP record for a system that was, in fact, GxP.
• Periodic reconciliation that checks the baseline and change history but never checks whether the ITIL and GxP populations agree in the first place.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Decide your connection pattern in 5.1 before anything else; do not proceed with the rest of this procedure undecided.
3. Point every cross-reference in sections 2 and 5.4 to your real patch management, emergency change, change control, and deviation procedures.
4. Set your reconciliation cadence in 5.2 and 5.6 to your system population’s size and risk profile.
5. Confirm every regulation in section 8 against the current published version, including the in-force status of Annex 11, before issue.