PLC Program Version Control
on Validated Systems

The Real Requirement — It's Not About Git

Most version control discussions for PLC code focus on tooling: should you use Git, TFS, or the archive method built into TIA Portal? That's the wrong starting point. The GMP requirement that drives version control on validated systems is much more specific: you must be able to demonstrate, at any future audit, that the code in the controller today is the code that was qualified, and that any changes since qualification were made through change control.

EU GMP Annex 11 and the GAMP 5 framework both require that validated computerised systems — including the PLC software — are controlled such that unauthorised changes cannot be made and that every authorised change is documented with a full record of what changed, why, and who approved it. The version control system is the mechanism that enforces this. It is not an engineering productivity tool on a pharma project — it is a compliance control.

Validation Baselines — The Fixed Points

The foundation of version control on a validated system is the concept of a baseline — a labelled, frozen version of the programme that corresponds to a specific validation event. Baselines are not just the latest tagged commit; they are the versions that are referenced in controlled documents and that cannot be modified after they are set.

There are three mandatory baselines on every pharma PLC project:

• FAT Baseline — the programme version used during the Factory Acceptance Test. This version is identified in the FAT protocol cover page and the executed FAT record. Any deviations raised during the FAT that require code changes result in a new minor version before IQ, not a modification of the FAT baseline.
• IQ Baseline — the programme version that was loaded in the controller when the IQ was executed. The IQ protocol includes a step that records the programme version and verifies it matches the expected version before IQ activities begin. This version is also recorded in the IQ execution record.
• OQ Baseline (Validated State) — the programme version in the controller when the OQ was executed and the system was declared validated. This version is recorded in the Validation Summary Report as the validated baseline. All post-validation changes are measured against this baseline via change control.

The principle is that once a baseline is set, it is permanent. You can create new versions after it, but you cannot retroactively modify what the baseline was. If an auditor asks to see the OQ baseline, you must be able to produce it exactly — not an approximation.

The Version Tag Format

A version tag on a pharma PLC project carries more information than a semantic version number alone. It must encode enough context to locate the associated change control or validation event without searching through separate records. The format used consistently in well-structured PLC projects combines three elements:

The major version number increments at each validation baseline. Minor version numbers track interim changes between baselines. The date and event reference make the tag self-documenting — anyone reading the tag can immediately identify what validation stage it relates to without cross-referencing a separate log.

One rule applies without exception: the version tag is applied before the code is loaded into the controller, not after. Tagging retroactively — adding a tag to a commit after the code has already been deployed — is not reliable evidence. The tag must exist before deployment, and the deployment record must reference the tag. This is what creates an unambiguous chain from version control to controller to qualification record.

Tooling — Three Approaches That Work

There is no single mandated tooling approach for PLC version control in pharma. What matters is that whatever system you use produces evidence that satisfies the GMP requirements. Three approaches are commonly used, each with different trade-offs.

Approach 1 — Vendor Archive Method (TIA Portal, Studio 5000)

Every major PLC development environment has a built-in archive or backup function. In TIA Portal this is the project archive (.zap file). In Studio 5000 it is the ACD archive. The archive method is simple and requires no additional tooling: at each version point, create an archive, name it according to the version tag format, and store it in a controlled network location.

This approach works well for smaller projects or teams without established DevOps infrastructure. The weaknesses are: archives are binary files, so you cannot diff them to see exactly what changed between versions; the "controlled network location" must actually be controlled (backed up, access-restricted, not a local hard drive); and there is no automated enforcement of the naming convention — human discipline is the only control.

Approach 2 — Git with Exported Source Files

TIA Portal and some other platforms support export of the project to XML or text-based formats that can be tracked in Git. Codesys-based platforms have better native Git integration. The advantage is a full diff history — you can see exactly which rungs or function block parameters changed between any two versions. The disadvantage is that the export/import workflow adds steps and the XML exports from TIA Portal are not always clean enough for reliable diff output.

For teams already using Git for other code, this approach scales better across multiple projects and provides a true audit trail with commit messages, author information, and timestamps that are not editable after the fact.

Approach 3 — Dedicated Configuration Management Tools

Some organisations use dedicated configuration management tools designed for OT environments — products that handle PLC programme versioning, compare deployed firmware against the approved version in real time, and generate configuration audit reports. These tools are particularly valuable in post-validation operations where regular code comparison verification is a periodic review requirement. The cost is higher, but the compliance evidence they generate is stronger than either of the first two approaches.

What Gets Versioned — Not Just the Programme

A common gap is treating version control as applying only to the PLC programme (the .ap15 or .ACD file). On a validated system, version control applies to everything that constitutes the configured state of the controller:

• PLC programme — all function blocks, data blocks, organisation blocks, and the OB structure
• Hardware configuration — rack configuration, module assignments, I/O addresses, firmware versions of each module
• Drive and motion parameters — any VFD or servo parameters configured from the engineering tool that could affect process behaviour
• Safety programme — F-CPU programme is a separate compilation unit and must be versioned independently with its own safety CRC verification
• Failsafe parameter sets — the values that the outputs default to on CPU fault are a configurable item and must be documented and versioned
• Communication configuration — OPC server configuration, Profibus/Profinet device configuration, network addresses

The IQ protocol includes steps that verify each of these configuration items against the approved version. An IQ that only checks the programme version and not the hardware configuration, module firmware, or safety CRC is incomplete. The validated state is the entire configured system, not just the application logic.

Post-Validation Version Control — The Ongoing Discipline

Version control requirements don't end at OQ sign-off. In many ways they become more important post-validation, because now every change must go through formal change control and the version control record is part of the change control evidence package.

The process for a post-validation code change is: raise a change control record, get it approved, make the code change, tag the new version referencing the CCR number, load the verified version to the controller, execute the required testing per the change control risk assessment, update the change control record with the result, and update the Validation Summary Report to reflect the new baseline if the change is major. The version tag is the link that connects the change control record to the code archive and to the controller state.

What the VSR Needs From Version Control

The Validation Summary Report must include a section that identifies the validated baseline — specifically, the programme version number that was verified in the controller at OQ completion, with a statement that this version is the validated state. It also lists any programme versions that existed during the qualification lifecycle (FAT baseline, any deviation corrections) and confirms that each interim version change was handled through the appropriate process (change control for post-FAT changes, deviation management for changes made during active protocol execution).

If the VSR version baseline and the version control archive don't tell the same story — if the VSR says v3.0 is the validated state but the archive shows no tag for v3.0 or the tag date is after the OQ completion date — you have a documentation nonconformance that will require a corrective action record to resolve.