This is a ready-to-use triage form for the question that decides everything downstream of an IT or infrastructure change: does it touch a validated GxP system, and if so, how fast and how formally does it need to move. It is built for changes that are not necessarily patches, a firewall rule, a hypervisor migration, a storage change, a DNS or load balancer change, a cloud vendor notice, so it is a companion to, not a replacement for, the classification table embedded in the Patch Management SOP. It is the working attachment to the IT Change Management Interface SOP. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. Verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Form title | GxP-Impact Triage and Change Classification |
| Form / record number | <<FILL: FORM-ID, e.g. FRM-IT-005-01>> |
| Parent SOP | <<FILL: IT change management interface SOP-ID>> |
| Change reference (ITSM / ITIL ID) | <<FILL>> |
| Date raised | <<FILL>> |
| Completed by | <<FILL: name, role>> |
1. Change summary
| Field | Entry |
|---|---|
| Change description | <<FILL: what is changing, in enough detail to assess without a meeting>> |
| Requesting team | <<FILL: e.g. network engineering, database administration, security operations>> |
| Target system(s) or infrastructure | <<FILL: server, network segment, storage array, cluster, or "unknown, see triage">> |
| Change type | <<FILL: patch / configuration / network / storage / virtualization / cloud vendor notice / other>> |
2. The triage question
| # | Question | Answer | Basis |
|---|---|---|---|
| 1 | Does the change touch a system, or the infrastructure a system depends on (server, network path, storage, time source, interface), that is flagged GxP in the CMDB? | Yes / No | <<FILL: CMDB query result, CI IDs checked>> |
If No: record the CMDB query evidence and close this form; the change proceeds under the IT change process alone. If the CMDB has no record either way for the target infrastructure, treat the answer as provisionally Yes until the configuration manager confirms otherwise; do not default an unknown to “No.”
If Yes: continue to section 3.
3. Classification questions
Answer in order; stop at the first “Yes.”
| # | Question | Answer | If Yes, route to |
|---|---|---|---|
| 1 | Must this happen now to restore service or security, with no time for prospective approval? | Yes / No | Emergency: Emergency Change Work Instruction |
| 2 | Is this a repeatable, previously characterized change type with a standing regression test already defined, and no GxP-relevant behavior change expected? | Yes / No | Pre-approved (standard): standing test set <<FILL: reference>>, or Patch Management SOP if the change is a patch |
| 3 | Does this touch a critical GxP function, a baseline setting with a material behavior change, or system architecture? | Yes / No | Major: full change control per <<FILL: change control SOP-ID>>, formal impact assessment |
| 4 | None of the above | (default) | Normal: change control per <<FILL: change control SOP-ID>>, targeted regression testing |
4. Classification and routing decision
| Field | Entry |
|---|---|
| Classification assigned | Pre-approved / Normal / Major / Emergency |
| Rationale | <<FILL: tie explicitly to the question answered Yes in section 3, not to the requestor's own label for the change>> |
| Governing procedure and reference | <<FILL: SOP-ID and, once opened, the change control or emergency record ID>> |
| CMDB and network/dependency relationships checked | <<FILL: list the CIs and dependency relationships reviewed, e.g. NTP source, mail relay, validated interface>> |
5. Acceptance criteria
- The triage question in section 2 is answered from an actual CMDB query, not from memory or assumption, and a “No” is recorded, not silently discarded.
- An infrastructure target with no CMDB record either way is treated as provisionally GxP-relevant, never defaulted to “No.”
- The classification in section 3 stops at the first “Yes” encountered, in order, and the rationale in section 4 cites the specific question, not the requestor’s own description of the change.
- Every “Yes” triage outcome is routed to a named governing procedure and reference before implementation, except under the emergency path’s own contemporaneous rule.
- The form is retained and reconcilable against the periodic ITIL-to-GxP population check in the parent SOP.
6. Signatures
| Role | Name | Signature | Date |
|---|---|---|---|
| Completed by | <<FILL>> | ||
| Reviewed by (configuration manager, for CMDB accuracy) | <<FILL>> |
7. References
EU GMP Annex 11, clause 10 (controlled change) and clause 4.3 (system inventory). Confirm the in-force version before issue. 21 CFR 211.68(b) (changes by authorized personnel); 21 CFR 11.10(k)(2) (revision and change control). GAMP 5 Second Edition (ISPE, 2022); PIC/S PI 011-3.
Confirm the current version and clause numbers before issue.
Filled specimen
Illustrative non-patch infrastructure change. Replace with your own.
| Field | Entry |
|---|---|
| Change reference | ITSM-2026-4471 |
| Change description | Tighten outbound firewall egress rules on the corporate network segment following a security incident elsewhere in the company |
| Requesting team | Security operations |
| Change type | Network / firewall |
| Triage question | Yes. CMDB query on the affected segment’s dependency relationships shows CI-LIMS-MAILRELAY-01, the SMTP relay a validated LIMS uses for release notifications, sits on this segment |
| Classification question 1 (emergency) | No; the tightening is scheduled, not an active incident response on this segment |
| Classification question 2 (pre-approved) | No; egress rule changes of this kind are not on the standing pre-approved list and this specific rule has not been characterized before |
| Classification question 3 (major) | No; the LIMS notification function is not a critical GxP function (it is an administrative notification, not a release decision), and no baseline setting changes |
| Classification (default, question 4) | Normal |
| Rationale | Routed Normal because none of the emergency, pre-approved, or major criteria applied; the LIMS mail-relay dependency was real but the function affected is a notification, not a release-critical path, so targeted testing rather than full revalidation is proportionate |
| Governing procedure | Change control for validated systems SOP-ID SOP-VAL-021; opened as CC-2026-0233 |
| CMDB relationships checked | CI-NET-FW-014 (the firewall CI), CI-LIMS-MAILRELAY-01 (dependency), CI-LIMS-APP-001 (parent system) |
Without the dependency relationship recorded against the firewall CI, this request would have shown no GxP system anywhere in its description, and the triage question in section 2 would have been answered No by a reviewer with no way to know otherwise.
Common findings this form prevents
- A network or infrastructure change assessed only on the requestor’s own description, which rarely names a GxP system because the requesting team does not think of itself as touching one.
- An unknown or unlisted piece of infrastructure defaulted to “not GxP” for convenience rather than confirmed.
- A classification set from habit or from the fastest available path rather than from the decision questions in order.
- A “Normal” or “Major” change implemented before its governing procedure’s own approval gate closed, because this triage step was treated as the only gate needed.
How to adapt this form
- Set your form number and point the parent-SOP field at your IT change management interface procedure.
- Keep the classification questions in the stated order; the order is what prevents both over-classifying everything as an emergency and under-classifying everything as pre-approved.
- If you run change intake in a workflow tool, map section 2 and section 3 to system fields and require a CMDB query result, not free text, in the basis column.
- Confirm every regulation in the references against the current published version before issue.