For QA teams, Responsible Persons and system owners

What EU GMP Annex 11 asks of a monitoring system

Annex 11 expects a computerised monitoring system to be validated for its intended use and kept that way: risk-based, with records that can't be quietly changed, an audit trail someone reviews, controlled access, and data that survives a failure or the end of a contract. There is no "Annex 11 certification": it is EU GMP guidance; GDP 3.3.1 requires validated systems, and inspectors use Annex 11 as the benchmark. You show compliance with evidence. Sematics validates the platform under a validation lifecycle aligned to EU GMP Annex 11, and gives you the evidence for your supplier assessment; ask us for the current status and the latest approved documents under the quality and technical agreement. JTF validates the monitoring system it supplies; for your own fridges, freezers and rooms, our temperature mapping gives you the evidence for their qualification, and validating your processes stays with you.

Updated 18 October 2026Reviewed by Jake Farrow, Managing Director

At a glance

What it asks

Who proves what

Annex 11 for a cloud monitoring platform, split by who controls each part

Each party evidences what only it can. Sematics validates the platform and verifies each release according to its risk, you qualify your configuration and use, and some clauses need both. You stay accountable for your reliance on the system, as Annex 11 expects.

Responsibility under Annex 11
  1. SematicsThe platformAt each release, by risk, and at periodic review
    • Requirements, risk assessment and design
    • Each release assessed and verified according to its risk
    • Data exchange, storage, printouts and backups
    • Hosting, security and incident handling
  2. SharedAgreed between youSet out in the quality and technical agreement
    • Risk management and personnel
    • Supplier oversight and audit
    • Audit trail: recorded by the platform, reviewed by you
    • Change control, periodic review, continuity and archiving
  3. YouYour useAt go-live, then under your change control
    • Assess Sematics and approve your reliance on its evidence
    • Your requirements (URS), configuration (DQ) and use (PQ)
    • Your users, roles and procedures
    • Review of audit trails and alarm logs

Platform validated by Sematics + shared controls under the QTA + your qualification = the Annex 11 evidence your inspector sees

Computer system validation, release by release
  1. RequestEach change described, with its requirement and acceptance criteria
  2. Review and classifyReviewed by a second engineer, and classified by risk from the change itself
  3. Verify by riskVerified according to its risk class, on an environment built from the release
  4. Report and approveThe programme's verification report for the release, sealed and reviewed by people who didn't produce it
  5. Minor or majorReleases that change validated behaviour notified in advance, with a configuration regression report
  6. Deploy and checkThe software verified is the software deployed, checked after deployment
What the July 2025 draft makes explicit
ControlAnnex 11 (2011)July 2025 draftSematics designs to
Data integrity to ALCOA+·✓✓
Alarms: settings, signalling, acknowledgement, log, review·✓✓
Unique accounts, strong authentication, inactivity logout, access log·✓✓
Independent, timely audit trail review·✓✓
Supplier oversight✓✓✓
Patching, security testing, encryption, firewalls·✓✓
Backup restore tests✓✓✓
Read-only archives·✓✓
Periodic review✓✓✓

A tick means the text sets an explicit requirement on the theme. Where the draft is stricter, Sematics applies the draft.

Traceability, from requirement to result
  1. RequirementsWhat customers rely on the platform to do, each one verifiable
  2. Functional designHow the platform meets each requirement
  3. Platform specificationEvery object, operation, role and permission, reviewed against the requirements
  4. TestsUnit, contract, integration, end-to-end and screen tests
  5. ResultsReported for each requirement in the programme's verification report for the release

Every test cited as evidence traces back to a requirement, and every requirement is covered by passing tests or a recorded justification.

Clause by clause

How Sematics approaches Annex 11

Every area of Annex 11 (2011), who is responsible for it, and how the Sematics validation programme addresses it. Where the July 2025 draft asks more, the programme applies the stricter draft requirement. The detail is in the validation package, provided to customers under the quality and technical agreement; ask us for its current status.

  1. PrincipleValidation and qualificationSematics and customer

    Sematics validates the application against its requirements under a validation lifecycle aligned to Annex 11, verifying each release according to its risk, and the hosting infrastructure is qualified by Sematics through a documented assessment of the provider, including its independent security certifications. Your performance qualification shows your use of it doesn't raise the risk to your process.

  2. 1Risk managementSematics and customer

    Risk is assessed following ICH Q9(R1) and the risk-based approach of GAMP 5: every function and record is classified by its effect on product quality, patient safety and data integrity, testing is concentrated on the most critical, and every change is classified by risk from the change itself. You assess the risks of your own use in your requirements and qualification.

  3. 2PersonnelSematics and customer

    Roles and responsibilities are defined for Sematics, its partners and the customer. Sematics, JTF and partner staff are trained for their roles before doing the work, with checks of understanding, records and refreshers, including security awareness. You train your own users.

  4. 3Suppliers and service providersSematics and customer

    A quality and technical agreement with each customer sets out each party's duties and provides for audit and inspection support. Sematics classifies its own suppliers by their effect on records, assesses them before relying on them and oversees them; partners such as JTF work under a written authorisation. You review the validation package and approve your reliance on it.

  5. 4ValidationSematics and customer

    Requirements are traced through the functional design and the platform specification to tests and their results, and each release is assessed and verified according to its risk. Sematics is introducing an automated release validation pipeline, and its validation programme includes a verification report for each release and a validation summary; ask us for the current status and the latest approved documents under the quality and technical agreement. You state your requirements (URS) and qualify your configuration (DQ) and use (PQ); data moved from an older system is verified.

  6. 5DataSematics

    Each hardware adapter decodes its protocol, checks message integrity where the protocol allows, and attributes every reading to a device. Decoding of every authorised hardware model is verified under the validation programme.

  7. 6Accuracy checksSematics and customer

    Changes to settings that matter, such as alarm limits, are checked for plausibility and read back with old and new values for confirmation and a reason. You check your configuration in your DQ.

  8. 7Data storageSematics

    Readings can't be changed or deleted by users, and records are kept for the period agreed with you. The programme provides for regular backups, with restoration tested in release verification and in periodic restore tests.

  9. 8PrintoutsSematics

    Reports and exports of conditions, incidents and the audit trail are available within each user's permissions, each with an identifier and a checksum of its content.

  10. 9Audit trailsSematics and customer

    The platform records every creation, change and deletion with the user, role, time, old and new values, and the reason for changes to key settings; it can be searched and exported. You review it under your procedures.

  11. 10Change and configuration managementSematics and customer

    Every platform change is requested, reviewed by a second engineer, classified by risk and recorded. A release that changes validated behaviour is major, notified in advance with a configuration regression report against your configuration; others come with release notes. Changes to your configuration go through your change control, against the baseline from your DQ.

  12. 11Periodic evaluationSematics and customer

    The Sematics programme provides for a review of the validated state at least once a year and after significant change, covering releases, deviations and CAPA, incidents, security, restore tests, supplier performance, training and audits. You review your use of the platform in your own periodic review.

  13. 12SecuritySematics and customer

    Named accounts, two-factor login on by default for every user (a company-wide setting to enforce it is being added), role-based permissions by company, site, zone and asset, and separation of each customer's data, which is tested. Data is encrypted in transit (TLS 1.2 minimum, 1.3 by default) and backups are encrypted at rest. You decide who holds which role, and every grant, change and removal is recorded.

  14. 13Incident managementSematics

    The programme is designed so that a failed test on a critical function raises a deviation automatically; others are raised by people. Each is contained, assessed for its effect on customers' records, and fixed at its root through corrective and preventive action, with effectiveness checked before closure. Incidents that affect you are notified under the quality and technical agreement.

  15. 14Electronic signatureNot applicable

    The platform doesn't apply electronic signatures to records. Acknowledgements and other actions are attributed entries in the audit trail; where your procedures need a signature, it goes on a printed record carrying an identifier and checksum. That is a hybrid record; see the Chapter 4 draft, which says to avoid them.

  16. 15Batch releaseNot applicable

    The platform has no batch certification or release function.

  17. 16Business continuitySematics and customer

    The Sematics programme sets recovery objectives and a disaster recovery plan, with restoration and recovery tests. You set out alternative monitoring during any downtime in your own continuity procedure.

  18. 17ArchivingSematics and customer

    Records stay in the platform, readable through platform changes, for the agreed retention period. If the contract ends, they are exported to you in the formats agreed in the quality and technical agreement.

Annex 11 1, 4, 11

Validation lifecycle, risk and release verification

What it says

Validate the system across its lifecycle, with documentation and test methods justified by risk. Keep an inventory and a description of the system, and user requirements traceable through to testing. Make changes only under a defined procedure, and evaluate the system periodically to confirm it is still valid and compliant.

What it means on site

A cloud platform changes far more often than software on a PC, so a one-off validation goes stale quickly. Sematics runs a continuous lifecycle instead. Risk is assessed function by function, following ICH Q9(R1) and the risk-based approach of GAMP 5, so testing concentrates on what protects your records: alarms, notifications, the audit trail, access and the readings themselves. Each requirement traces through the functional design and the platform specification to its tests. Each release is assessed and verified according to its risk, and Sematics is introducing an automated release validation pipeline that runs the tests on an environment built from the release and seals the results so any later change would show. Sematics's validation programme includes a verification report for each release, reviewed by people who didn't produce the work, a validation summary, and a periodic review at least once a year that asks whether the validated state still holds; ask us for the current status and the latest approved documents under the quality and technical agreement.

How to evidence it

  • The platform validation package: methodology, requirements, risk assessment and traceability
  • The release verification evidence for the version you run, and the current status of the validation summary
  • Your URS, DQ and PQ, approved by your QA
  • Periodic review records, yours and the supplier's

Annex 11 10, 13

Change control, releases and deviations

What it says

Make changes to a computerised system only in a controlled way, under a defined procedure. Report and assess all incidents, not only system failures and data errors; find the root cause of a critical incident and use it as the basis for corrective and preventive action.

What it means on site

Every platform change is requested with its requirement and acceptance criteria, reviewed by a second engineer, and classified by risk from the change itself, so no developer judges alone whether a change matters. Changes are released together and verified according to their risk. A release that changes validated behaviour is major: you are told in advance and get the release documentation and a configuration regression report, the release run against your own exported configuration. Minor releases come with release notes. If something goes wrong, the programme raises a deviation (designed to be automatic for a failed test on a critical function), which is contained, and assessed for its effect on each customer's records. Records are never altered to fix an error; a supplementary record states the correction. CAPA removes the cause and is checked for effectiveness.

How to evidence it

  • Release notes and documentation for each release, and the configuration regression report for each major release
  • Your assessment of each release under your change control, and your check after deployment
  • Your system release manifest: the exact versions you run
  • Notifications of any deviation that affected your records, with the action taken

Annex 11 5 to 8

Data integrity to ALCOA+

What it says

Build checks into electronic data exchange, check the accuracy of critical data entered by hand, secure stored data against damage and keep it accessible, and be able to produce clear printed copies. Inspectors read this with the data integrity guidance: records must be attributable, legible, contemporaneous, original and accurate, and complete, consistent, enduring and available (ALCOA+).

What it means on site

Readings arrive from authorised hardware only, are checked and attributed to a device, and can't be edited or deleted by any user. Changes to alarm limits and other key settings are read back for confirmation with a reason. Every report carries an identifier and a checksum, so a printed copy can be tied back to the record.

How to evidence it

  • The system description: what is measured, how readings reach the platform, where they are stored
  • A sample report or export with its identifier and checksum
  • The audit entry for a recent change to an alarm limit, with the reason
  • Your data integrity procedure and how it covers the monitoring system

Annex 11 9

The audit trail, and who reviews it

What it says

Based on risk, consider building in an audit trail of GMP-relevant changes and deletions; document the reason for each change; keep it available, readable and regularly reviewed.

What it means on site

The platform records the who, what, when and why; the review is yours. The audit trail can't be switched off or edited, and each incident has its own timeline that serves as its alarm log. The customer qualification guidance points to the entries of greatest significance, so a monthly review can focus on alarm limits, roles and acknowledgements rather than reading every line.

How to evidence it

  • Your procedure for audit trail and alarm log review: who, how often, what they look for
  • Records of completed reviews, by someone independent of the activity
  • An exported audit trail for a period, searchable and complete

Annex 11 12

Access and security

What it says

Restrict access to authorised people by physical and logical controls, proportionate to the system's criticality. Record the creation, change and cancellation of access, and record the identity of anyone who enters, changes, confirms or deletes data, with the date and time.

What it means on site

Every user has a named account, with two-factor login on by default (a company-wide setting to enforce it is being added); shared logins are out. Sessions end after inactivity, logins and logouts are logged, and each customer's data is separated from everyone else's, which is tested by trying every operation for every role, inside and outside its scope. Around that, connections are encrypted (TLS 1.2 minimum, 1.3 by default), backups are encrypted at rest, the network allows only the connections each service needs, administrative access is limited to named people and reviewed, and the sensor gateway connects outbound only, over TLS with a client certificate. No one edits customer records directly in the database. You decide who holds which role and review the list regularly.

How to evidence it

  • Your user list with roles, and the record of your last access review
  • The audit trail of users invited, changed and disabled
  • The supplier's security and data protection statement, in the validation package

Annex 11 2, 3

Suppliers, people and oversight

What it says

Put formal agreements in place with third parties that provide, configure, validate or operate a system, with clear responsibilities. Consider a supplier's competence and reliability, audit based on risk, and review the documentation supplied with commercial products. Everyone involved should have the qualifications, access and responsibilities their tasks need, and work closely together.

What it means on site

With software as a service, you rely on Sematics for the platform, but you stay accountable for that reliance. The quality and technical agreement sets out each party's duties, provides for audit, and commits Sematics to provide its validation documentation and a knowledgeable person to support your inspections. Sematics applies the same discipline to its own suppliers: each is classified by its effect on records, assessed before it is relied on and overseen, with the largest providers judged on their independent security certifications. JTF works as an authorised Sematics partner for hardware and qualification in the UK, under a written authorisation. Sematics, JTF and partner staff are trained for their roles before doing the work, and the programme provides for internal audits by people independent of the work, with management review, to check the procedures are followed and still work.

How to evidence it

  • The signed quality and technical agreement
  • Your assessment or audit of Sematics
  • Your written approval of reliance on the platform validation for the version you use
  • Training records for anyone who installs, configures or qualifies your system

Annex 11 7, 16, 17

Continuity, backup and archiving

What it says

Back data up regularly and check that it can be restored. Make documented, tested provisions to keep critical processes going if the system breaks down. Check archived data for accessibility, readability and integrity, and make sure it can still be retrieved when the system changes.

What it means on site

Readings are held by the hardware and the platform's message streams until they are safely stored, so a short failure delays readings rather than losing them. The programme provides for regular backups, kept separate from the systems that write the data and copied to a second location, with restoration tested in release validation runs and scheduled restore tests, defined recovery objectives and recovery exercises; after any restoration the records are checked before customers get the platform back. Records stay in the platform for the retention period you agree, and are exported to you if the contract ends. Your part is the plan for monitoring during any downtime, because no platform can notify while it is down.

How to evidence it

  • The supplier's continuity, backup and recovery statement, from the validation package
  • Your business continuity procedure, including alternative monitoring
  • The retention period and export formats agreed in the QTA

Annex 11 draft, July 2025

The July 2025 draft: the stricter text applied now

What it says

The European Commission and PIC/S published a revised Annex 11 for consultation in July 2025. It is far more detailed than the 2011 text and is not yet adopted. It strengthens data integrity (ALCOA+); alarms (settings, signalling, acknowledgement, the alarm log and its review); identity and access (unique accounts, strong authentication, inactivity logout, an access log, recurrent reviews); independent and timely audit trail review; supplier oversight; security (patching, penetration testing, encryption, firewalls); backup and restore tests; read-only archives; and periodic review.

What it means on site

The Sematics validation is assessed against the 2011 text in force, and where the draft is more stringent, the stricter draft requirement is applied. Several of its demands are about design, such as alarm logs, access controls and audit trail content, which are better built in now than added after adoption. A separate July 2025 draft, Annex 22, covers AI: no machine learning model is used in any platform function.

How to evidence it

  • The supplier's mapping of each clause of the 2011 text and the draft, in the validation package
  • Your alarm log review and access review records, which the draft asks for explicitly

In the inspector's words

Questions to be ready for

The kind of questions an inspector, assessor or auditor puts. If you can answer each with a record, you're ready.

  1. “Which version of the monitoring system are you running, and where is its validation evidence?”
  2. “How did you assess the supplier, and what does your agreement with them say?”
  3. “Who reviewed the audit trail last month, and what did they find?”
  4. “Show me how one requirement traces to its test result for this release.”
  5. “How were you told about the last major release, and what did you do about it?”
  6. “Who can change this alarm limit, and where would I see that they did?”
  7. “When did you last review who has access?”
  8. “How do you know a backup can be restored?”
  9. “What happens to these records if the service goes down, or the contract ends?”

Where JTF fits

Three layers, one qualification package

A Sematics by JTF system is qualified in three layers: JTF qualifies the hardware at your site (IQ and OQ), Sematics validates the platform under a validation lifecycle aligned to EU GMP Annex 11, and gives you the evidence for your supplier assessment, and we help you write your URS and qualify your configuration and use (DQ and PQ). We validate the monitoring system we supply; for your own fridges, freezers and rooms, our temperature mapping gives you the evidence for their qualification, and validating your processes stays with you. Calibration for every sensor we supply: traceable to national standards as standard, or UKAS accredited where you need it (temperature in our own UKAS accredited calibration laboratory No. 10723; other parameters through accredited partners).

Checklist

Annex 11 at a glance

Every Annex 11 area, who is responsible and how Sematics approaches it, on three pages.

Get Annex 11 at a glance

Free download

Annex 11 at a glance

The clause grid on this page as a three-page PDF for your QA file: each Annex 11 area, who is responsible, how Sematics approaches it, and what the July 2025 draft adds.

  • Page 1 of Annex 11 at a glance, preview
  • Page 2 of Annex 11 at a glance, preview
  • Page 3 of Annex 11 at a glance, preview

Customers: the full validation package is provided under the quality and technical agreement. Ask your account manager.

Tell us where to send it. The link appears as soon as you press the button.

We use your details to reply to this request, nothing else. See our privacy notice.

The 20-minute compliance check

See your own gaps, in writing

A free call with one of our specialists, then a branded report of what an inspector would find, yours to keep. This is an example.

Example reportExample report: MHRA GDPA pharmaceutical wholesaler (fictional)Download the PDF
Example report: MHRA GDP
Page 1 of the example report: mhra gdpPage 2 of the example report: mhra gdpPage 3 of the example report: mhra gdp

Related

Keep reading

Questions

Common questions

Is there such a thing as Annex 11 certification?

No. Annex 11 is EU GMP guidance for regulated users, and nobody certifies a system against it. A supplier can validate its system to Annex 11 and give you the evidence; you assess that evidence, qualify your own use, and show both to your inspector.

Does Annex 11 apply to GDP and wholesale distributors?

GDP 3.3.1 requires computerised systems to be validated or verified before use, but doesn't say how. Annex 11 is the reference inspectors generally use for that, so a monitoring system validated to Annex 11 answers the GDP requirement too. See MHRA GDP.

What is the difference between CSV and IQ, OQ and PQ?

Computer system validation (CSV) shows the software does what it should, reliably, across its lifecycle. IQ and OQ qualify the hardware installed at your site, and PQ shows the whole system performs in your operation. For Sematics, JTF does hardware IQ and OQ, Sematics does CSV of the platform, and you do URS, DQ and PQ with our help. See validation.

If Sematics verifies the platform, what is left for us?

You stay accountable for your use of the system. You assess Sematics, approve your reliance on its validation for the version you use, qualify your configuration and use (URS, DQ, PQ), manage your users, review the audit trail and alarm logs, and include the system in your periodic review.

How does Sematics maintain the platform's validated state between inspections?

By treating each release as its own evidence. Every change is reviewed and classified by risk, each release is assessed and verified according to its risk, and major releases come with a configuration regression report against your configuration. Sematics's validation programme includes a verification report for each release, a validation summary, CAPA for deviations and a periodic review at least once a year; ask us for the current status and the latest approved documents under the quality and technical agreement.

What does traceability look like for a cloud platform?

Each platform requirement is traced through the functional design and the platform specification (every object, operation, role and permission) to the tests that verify it, and from each test to its result in the programme's verification report for the release. A requirement without passing tests is either justified or holds up the release.

How are backups and recovery tested?

The programme provides for restoration tests in release validation runs and in scheduled restore tests, and for recovery exercises against defined recovery objectives; a recovery that loses records or misses an objective is handled as a deviation. Backups are kept separately from the systems that write the data and copied to a second location. Ask us for the current status of these tests.

Who checks that Sematics follows its own procedures?

The programme provides for internal audits by people independent of the work, a management review of releases, deviations, security, supplier performance and training, and the periodic review of the validated state. Sematics, JTF and partner staff are trained for their roles and refreshed. Under the quality and technical agreement, you can audit Sematics as well.

Should we be working to the July 2025 draft already?

It isn't adopted yet, and inspections are against the 2011 text. But the draft shows what inspectors expect, and much of it is about how the system is built. Sematics applies the stricter draft requirement wherever the draft asks more, so less of your evidence should need rebuilding; the mapping will be rechecked against the adopted text.

Does Sematics use electronic signatures?

No. Acknowledgements and other actions are recorded as attributed entries in the audit trail: who, in what role, and when. Where your procedures need a signature, it goes on a printed record that carries an identifier and a checksum, so the copy can be tied back to the record. That is a hybrid record, which the Chapter 4 draft says to avoid.

Does the platform use AI?

No machine learning model is used in any platform function, so the July 2025 Annex 22 draft on AI in critical GMP applications doesn't apply to it. In the validation itself, generative AI may help draft documents and test code, but it never classifies changes, decides test results, closes deviations or approves anything: qualified people review its output and take responsibility for it.

On LinkedIn

Rules, results and what inspectors ask, every week.

Follow JTF Wireless for plain-English compliance notes, case studies and news from the lab.

Follow JTF Wireless

Next step

Ask for the validation package

Customers and prospective customers receive the platform validation evidence under a quality and technical agreement. Tell us who should receive it and we'll set that up.