This is a ready-to-use record for the deeper system description EU GMP Annex 11 expects for critical (High-tier) computerized systems, beyond the one-line inventory entry: an up-to-date document detailed enough to show how the system is arranged, how data moves through it, how it connects to other systems, what it depends on to run, and how it is secured. The inventory flags which systems owe this; this record is the document itself. Replace every <<FILL: ...>> placeholder and route it through your normal document control. Field definitions and a filled specimen follow. The context is in the GxP computerized system inventory and classification; Annex 11 is copyrighted, so describe its contents in your own words and confirm the current (and pending draft) text before you rely on it.
When this record is required
Maintain a system description for every High-tier system, meaning one with direct impact on product quality, patient safety, or batch-release/disposition decisions, or that holds critical GxP records. It is a living document: update it whenever the architecture, data flows, interfaces, or security posture change, under change control, and reconfirm it at periodic review. A draft Annex 11 revision (consultation 7 July to 7 October 2025, final expected mid-2026) sharpens the security expectations, so treat the security section as central, not optional.
Record control header
| Field | Entry |
|---|---|
| Document title | System Description, <<FILL: SYSTEM NAME>> |
| Document number | <<FILL: DOC-ID>> |
| Version | <<FILL: version>> |
| Effective date | <<FILL>> |
| Linked inventory ID | <<FILL: SYS-nnnn>> |
| System owner (business / IT) | <<FILL>> |
| Next review date | <<FILL: per tier>> |
1. System identity and purpose
| Field | Definition | Entry |
|---|---|---|
| System name / inventory ID | Name and the inventory row it maps to | <<FILL>> |
| GxP function | What GxP records/decisions it serves | <<FILL>> |
| Risk tier / GAMP category | From the inventory | <<FILL: High; Category 4>> |
| Predicate rules / records | Which regulated records it holds | <<FILL>> |
| Validation status | Report reference and date | <<FILL>> |
2. Physical and logical architecture
Describe how the system is built: clients, application and database servers, whether on-premises, hosted, or SaaS, and the environments (production, validation/test, development). A simple labeled diagram or a component list is acceptable; the point is that a reader can see the moving parts.
| Component | Role | Location / host | Environment |
|---|---|---|---|
<<FILL: client>> | <<FILL>> | <<FILL>> | Production |
<<FILL: app server>> | <<FILL>> | <<FILL>> | Production |
<<FILL: database>> | <<FILL>> | <<FILL>> | Production |
3. Data flows
Describe the path of GxP data from creation to storage to any downstream use: where a record is created, how it is transformed, where it is stored, and where it goes next. Name the critical data and its lifecycle stages.
| Data element | Created where | Transformed how | Stored where | Sent where |
|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
4. Interfaces and dependencies
List every connection to another system (inbound and outbound) and every service the system needs to run correctly (identity provider, time service, network, database platform). An interface that moves GxP data is itself a control point.
| Interface / dependency | Direction | Data / service | Control on the interface |
|---|---|---|---|
<<FILL: LIMS>> | Outbound | Result transfer | Verified mapping, checksum |
<<FILL: time service>> | Dependency | Traceable time | Locked clock source |
<<FILL: identity provider>> | Dependency | Authentication | RBAC, no shared accounts |
5. Prerequisites to run
State the hardware and software the system requires: operating system and version, database platform, runtime, and any Category 1 infrastructure it relies on and where that qualification is recorded.
| Prerequisite | Version | Qualification reference |
|---|---|---|
<<FILL: OS>> | <<FILL>> | <<FILL>> |
<<FILL: database>> | <<FILL>> | <<FILL>> |
6. Security measures
Describe how the system and its data are protected: access control model, authentication, privilege separation and segregation of duties, audit trail configuration, backup and restore, disaster recovery, patching, and any encryption. This is the section the Annex 11 revision reinforces most.
| Control | How implemented | Evidence reference |
|---|---|---|
| Access control (RBAC) | <<FILL>> | <<FILL>> |
| Authentication | <<FILL: unique accounts, MFA>> | <<FILL>> |
| Audit trail | <<FILL: enabled, prior values, reviewed>> | <<FILL>> |
| Backup / restore | <<FILL>> | <<FILL: last restore test>> |
| Disaster recovery | <<FILL>> | <<FILL: last DR test>> |
| Patch / vulnerability management | <<FILL>> | <<FILL>> |
7. Acceptance criteria
- The description covers architecture, data flows, interfaces, dependencies, prerequisites, and security, at a depth a reviewer can follow.
- It maps to the inventory row and the validation package, and its version is current.
- Every interface that moves GxP data names its control; every dependency names what it provides.
- The security section reflects the system as configured today, with evidence references, not an aspirational design.
- It is updated under change control and reconfirmed at periodic review.
8. Filled specimen (abridged)
An illustrative description for a configured chromatography data system. The company, system, and numbers are illustrative; replace them with your own.
| Field | Value |
|---|---|
| System / inventory ID | QC Chromatography Data System / SYS-0042 |
| GxP function | Acquires, integrates, and stores release-testing chromatography results and e-signatures |
| Risk tier / category | High / Category 4 (configured); custom export = Category 5 component |
| Architecture | Thin clients to an on-premises app server and Oracle database; separate validation environment |
| Key data flow | Raw chromatograms created at the instrument, integrated and reviewed in the CDS, results transferred to LIMS via a validated interface |
| Interfaces / dependencies | Outbound to LIMS (verified mapping); depends on the domain identity provider (RBAC, no shared accounts) and an NTP-locked clock source |
| Prerequisites | Windows Server (IQ ref INF-2023-08), Oracle (INF-2023-09) |
| Security | RBAC with acquire/reprocess/no-delete for analysts; audit trail enabled with prior values and reviewed each run; nightly backup, restore tested 2025-09; DR tested 2025-09; monthly patch cycle |
In this example the description reads as a map: a reviewer can see the servers, the data path from instrument to LIMS, the two dependencies that could corrupt a record (identity and time), and the security controls as actually configured, each with an evidence reference. That is what “detailed enough” means for a critical system.
9. Common inspection findings this record prevents
- A critical system with only a one-line inventory entry and no maintained description.
- A description that no longer matches the system after undocumented changes.
- Interfaces moving GxP data with no stated control, so a transfer error is undetectable.
- A time or identity dependency that could corrupt records, never identified as a control point.
- A security section that describes the intended design, not the current configuration, with no evidence.
10. How to adapt this record
- Set your document number and link it to the inventory row and validation package.
- Fill each section from the as-configured system, not the original design intent, and cite evidence.
- Put this record under change control so architecture, interface, or security changes update it.
- Confirm the current and pending Annex 11 text before issue; describe its expectations in your own words rather than pasting clauses.