GxP software development: requirements, validation and traceability

Building software for a GxP environment for the first time, most teams underestimate not the technical complexity but the burden of proof. The real question is not “does it work?” but “can you demonstrate that it is fit for the intended purpose – and that it stays so over time?” That difference shapes every step of the development process.

1. What GxP covers – and what follows for software

GxP is an umbrella term for “Good x Practice” regulations: Good Manufacturing Practice (GMP), Good Clinical Practice (GCP), Good Laboratory Practice (GLP), Good Distribution Practice (GDP) and others. They come from different jurisdictions but share one logic: processes that affect product quality or patient safety have to be controlled, documented and verifiable.

For computerised systems two documents make this concrete above all: Annex 11 of the EU GMP guidelines (EudraLex Volume 4) and 21 CFR Part 11 of the US FDA. Both require essentially the same thing: that a system is validated for its purpose, that data stays attributable, provably unaltered and available across its retention period, and that access and changes are controlled.

Important for context: these requirements address the system in use, not a tool on the shelf. A development platform can bring prerequisites; “GxP-compliant” only ever applies to the specific application at a specific operator – and even then only with the corresponding process and evidence in place.

2. Intended use: the basis of every assessment

The intended use defines what a system is used for, which GxP-relevant data it processes, which decisions rest on it and which process steps it supports. Everything else – risk class, validation scope, test depth, retention obligations – derives from it.

A usefully phrased intended use answers at least:

• Which regulated process is supported, and to what extent?
• Which data is created, changed or analysed – and is it GxP-relevant?
• Which decisions are made on the basis of that data?
• What happens if the system produces wrong results or fails?
• Which interfaces exist to other validated systems?

Vague wording here comes back twice over: it leads either to excessive validation effort for uncritical functions or to gaps in exactly the functions that matter.

3. A risk-based approach: effort where the risk is

Annex 11 as well as the relevant industry guides – GAMP 5 above all – assume a risk-based approach. Not every function is tested to the same depth; what matters is the impact on product quality, patient safety and data integrity.

In practice that means classifying functions and deriving the test depth from that. A proven rough structure:

GAMP 5 also provides the distinction by software category – from infrastructure software through configured standard products to bespoke software. It matters because a platform decision directly affects the validation effort: what is expressed as configured platform behaviour has to be evidenced differently from individually programmed logic.

4. Validation planning: plan first, test second

Validation planning defines up front what is to be evidenced, by what means, by whom and against which acceptance criteria. It is deliberately a document that comes first – evidence whose criteria are only phrased afterwards is weak.

Typical scope:

• Scope and boundaries: what is part of the validation, and what explicitly is not?
• The risk assessment and the test depth derived from it.
• Requirements (user requirements) as the reference point for all evidence.
• Qualification steps – classically installation, operation and performance in the operating context.
• Responsibilities, approvals and handling of deviations.
• A supplier assessment where platform or third-party software is used.
• Maintaining the validated state: change control, periodic review, decommissioning.

The last point is the most frequently underestimated. Validation is not a project milestone but a state that has to be maintained – across updates, staff changes and infrastructure changes.

5. Requirements: no identifier, no evidence chain

In a GxP context requirements are not project artefacts but the anchor of the entire evidence trail. Every test, every deviation, every change ultimately refers to a requirement.

• Uniquely identified and stably versioned.
• Phrased testably: a requirement that cannot be tested cannot be validated either.
• Marked by GxP relevance – not every requirement is regulatorily relevant, and that distinction saves considerable effort.
• Linked to design, implementation, test and release – the traceability matrix is nothing other than the sum of those links made visible.

When that structure is enforced by tooling instead of maintained in a spreadsheet, most of the classic documentation work disappears. Not because less is evidenced, but because the evidence arises while working.

6. Testing: evidence instead of spot checks

Tests in a GxP context carry one additional formal requirement: results have to be attributable, traceable and retainable. A test run whose log disappears from the CI interface after 30 days is useless as evidence.

Proven practice:

1. The test case references the requirement. Without that link there is no statement about coverage.
2. Record the expected result before execution – expectations phrased afterwards are not a test.
3. Negative tests for high-risk functions: what happens with missing permissions, invalid values, aborts?
4. Store evidence with versions, linked to the exact software state (version, checksum, build).
5. Document and assess deviations instead of quietly adjusting test cases.

Automated tests are explicitly welcome here – they are reproducible, loggable and re-run on every change. Their regulatory weight depends, however, on the test environment, the test data and the analysis itself being controlled.

7. Audit trails: technically simple, organisationally demanding

An audit trail records who changed which GxP-relevant record, when and how – and, where required, for what reason. The technical requirements are modest; the demanding part is using it.

• Automatic and not switchable off for GxP-relevant data. A log that can be disabled in operation loses its evidential weight.
• Complete: old value, new value, timestamp, acting person, affected record.
• Protected against modification, with a clear separation of application and administration rights.
• Analysable: an audit trail you can only export as raw data effectively never gets reviewed.
• Reviewed regularly (audit trail review) – this is exactly the organisational burden no software takes off you.

When history is part of the platform instead of being reimplemented in every project, not only the development effort drops but also the risk of incomplete records. How CodamAI implements history and traceability technically is on the features page.

8. Electronic records and signatures

Where electronic records replace paper, additional requirements apply. The principle of data integrity has become the common denominator, often summarised as ALCOA+: data should be attributable, legible, contemporaneous, original and accurate – plus complete, consistent, enduring and available.

Concretely for implementation:

• unique, personal user accounts – no shared logins,
• role-based permissions with documented assignment,
• protection against unnoticed modification, including backup and restore,
• legibility across the entire retention period – also after a change of system,
• for electronic signatures: unambiguous attribution to a person, a visible link to the signed record and the meaning of the signature.

That last point is often treated as a purely technical question. It is first a process question: who may sign what with what meaning, and how is that trained and monitored?

9. Change control: maintaining the validated state

After release every change becomes an event requiring assessment. The central question is not “is the change small?” but “does it touch GxP-relevant functions?”.

A workable process covers:

• a change request with a domain justification and the affected requirements,
• a risk assessment including the impact on the validated state,
• defining the evidence required (tests, documents, requalification where applicable),
• approval by defined roles before it takes effect,
• updating the documentation and the traceability.

Tie the assessment to the risk class and the process stays manageable even at a high rate of change. That is precisely the precondition for using modern development speed in a GxP environment at all.

10. Roles and responsibility

GxP regulations address responsibility explicitly. In practice, software projects end up with four bundles of roles that have to be clearly assigned:

• Process owners – define the intended use and the domain requirements.
• System owners – are responsible for operation, configuration and the system life cycle.
• The quality unit (QA) – reviews and approves, independently of development.
• Supplier / development – delivers with evidence, is subject to a supplier assessment, but does not carry the operator's regulatory responsibility.

This separation is not a formality. It decides whether a release decision holds up in an audit.

11. AI use as an additional controlled factor

Using AI in development is no disqualifier in a GxP context – but it is a factor that has to be controlled like any other. Two entirely different cases have to be distinguished:

1. AI as a development tool. The model produces code or configuration; what ships is deterministic software. Validation still targets the result. What additionally needs governing are data flows, review duties and documentation of the tool's use.
2. AI as a function in the validated system. When a model influences GxP-relevant decisions at runtime, a separate and considerably more demanding question arises – including reproducibility, model versioning, data provenance and ongoing monitoring. That case deserves its own assessment and is not the subject of this article.

For the first case a modest addition to the existing rules is usually enough: which tools are approved, which data may go in, which checks are mandatory, and how the use is documented. The instruments themselves – review, test, traceability, change control – stay the same. What such a policy looks like is described in the deep dive AI coding governance.

How this fits into an end-to-end development process is described in the article on regulated software development with AI.

Checklist: a GxP software project

Conclusion

GxP requirements are no obstacle to modern software development. They are a requirement on the evidence – and evidence can be automated. Requirements with identifiers, models instead of implicit conventions, tests linked to requirements, history as a platform capability, reproducible builds and risk-based change assessment: that is the bulk of what audits actually ask about.

What remains is the organisational responsibility – intended use, risk assessment, release, training, monitoring. It cannot be delegated to a product, and no platform should claim otherwise.