GAMP 5 sorts software by the effort you invest, not by a vendor label
ISPE’s GAMP 5 Guide (Second Edition, 2022) sorts software into categories by the validation effort a regulated company should invest in it, scaled to risk. It runs from Category 1 (infrastructure software: operating systems, database engines, middleware and comparable software tooling) through Category 3 (non-configured products used as supplied) and Category 4 (configured products such as LIMS, ERP and eQMS platforms) to Category 5 (custom-built applications). Effort climbs with the category: infrastructure is qualified and leans on supplier evidence; configured and bespoke systems carry the full computerised-system validation (CSV) lifecycle.
Two points matter more than the number itself, and both work in your favour:
The category is yours to assign. GAMP is guidance for the regulated user, not a certificate a vendor stamps on a product. You classify software for the way you use it, which is why the useful thing we can give you is the reasoning and the supplier evidence, not a compliance badge.
Second Edition leans harder on leveraging supplier activity. Where a supplier’s own development, testing and security controls are documented and can be assessed, GAMP 5 Second Edition is explicit that you should use that evidence to reduce duplicated effort rather than re-testing from zero.
Where a drawing tool lands, and why
A P&ID editor produces documents. It is not the system that holds your approved record, and it does not calculate, release, or make a GxP decision. That one fact sets the category, and it sets it low. Which low category you assign is a secondary question, because the validation burden is the same either way.
The reading most QMS teams reach for is Category 3: a non-configured product used as supplied, verified for the features you actually rely on and leaning on the supplier’s documentation, and nothing more. Some teams instead treat an authoring tool that holds no record as Category 1, infrastructure-style software tooling that produces artefacts controlled downstream. That is the reading behind the “qualified, not validated” line you will see elsewhere on this site. Either is defensible, and the difference is immaterial: both come down to a supplier assessment plus a short, risk-based justification.
What the tool is not, under any reading, is a Category 4 or 5 system demanding a full validation project, because it is not your system of record. Assign the low category your QMS is most comfortable defending; the workload lands in the same place.
Authoring layer · PharmaDiagrams
Where the working drawing lives
- create
- share link
- comment on the tag
- version history
- export
Record-holding layer · your validated DMS
Where the GxP record is controlled
- Veeva Vault
- ValGenesis
- Part 11 controls
- predicate rules
One honest boundary: when you configure the tool for your organisation (users, roles, and, on the roadmap, the meaning of a signature), that configuration is yours to assess, and it is the slice a reviewer would treat as configured. It is a short, well-scoped exercise against how you set the tool up, not a validation of the whole application.
What this means for your validation burden
In practice, adopting a Category 1 authoring tool is a supplier assessment plus a short, risk-based assessment recorded in your QMS: for many teams, a one-page justification rather than a CSV project with IQ/OQ/PQ protocols. To support it, we provide a vendor compliance package on request: a system description, our software development lifecycle, and our change-control and security controls. Your team leverages that evidence, records the risk decision, and moves on.
No account needed.
This is the entire point of the tool category. A generic diagramming app was never built to be assessed against GAMP, so it gives your QA nothing to work with.
“Qualified, not validated”: the distinction in plain terms
Qualified · the tool
Qualification is the lighter assurance you apply to infrastructure and tooling: confirm it is what the supplier says it is, confirm it is fit for how you use it, keep the supplier evidence on file.
Validated · the record system
Validation is the evidence exercise you run over a system that holds or acts on your GxP data: your DMS, your LIMS, your MES.
Calling an authoring tool “validated” or “GxP-validated” would be a category error: it would invite scope that the tool neither needs nor supports, and it is precisely the claim we don’t make.
How to document the toolchain split for your QMS
The clean way to write this up is to name the split explicitly. PharmaDiagrams is the authoring layer: it is where the working drawing is created, shared, reviewed on the tag, and versioned. Your validated document system is the record-holding layer: the approved PFD or P&ID is exported into it and controlled there under your predicate rules. Your assessment references the two layers, categorises the authoring tool low (Category 1 or 3), points to our vendor compliance package for the supplier-evidence leg, and treats your own configuration as the part you assess. That paragraph, plus our evidence pack, is typically the whole of it.
The direction of travel: risk-based assurance
The regulatory trend is toward less ceremony for low-risk software, not more. The FDA’s Computer Software Assurance (CSA) guidance, finalised in 2025 and reissued in an updated final version dated 2026-02-03, presses a risk-based, least-burdensome approach: concentrate assurance effort where patient-safety and product-quality risk is highest, and apply little or none where it is not. Its formal scope is production and quality-system software under the device rules, but its philosophy is the direction the whole field is moving. In the EU, the EudraLex Volume 4 Annex 11 revision is expected to publish in 2026; we track it on the 21 CFR Part 11 page. Neither development turns a drawing tool into a system of record, and both make the low-burden treatment of tooling easier to defend, not harder.
See also: Are P&IDs 21 CFR Part 11 records? · How we hold your data (security)