Quality and technical agreements: who is responsible for your monitoring system

Why it matters

You stay accountable for what you outsource

The EU GDP guidelines are direct: "The contract giver is responsible for the activities contracted out", and "There must be a written contract between the contract giver and the contract acceptor which clearly establishes the duties of each party" (EU GDP 2013/C 343/01, 7.2 and 7.1). Chapter 7 of EU GMP Part I says the same for manufacturers: the contract giver is "ultimately responsible to ensure processes are in place to assure the control of outsourced activities", and the contract "should describe clearly who undertakes each step" (EU GMP chapter 7, 7.4 and 7.15).

For the software, EU GMP Annex 11 clause 3.1 applies when third parties "provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service": formal agreements must exist, with "clear statements of the responsibilities of the third party" (Annex 11, 3.1). A cloud monitoring platform does several of those things at once. Annex 11 is part of EU GMP: for a wholesaler under GDP only, GDP 3.3.1 and chapter 7 are the requirement, and Annex 11 is the benchmark inspectors refer to.

The 2025 consultation draft of Annex 11 goes further. It says relying on a vendor's or service provider's qualification or operation "does not change the requirements", and the regulated user "remains fully responsible" (draft 7.1). It is a draft and not in force, but it shows where inspectors' expectations are heading.

Who is involved

A monitoring system involves four roles

You, the regulated user. The licence or accreditation holder: a wholesaler, manufacturer, blood establishment, laboratory or hospital pharmacy. You own the records, set the requirements, approve the configuration and decide what an excursion means for the product.

The platform supplier. Provides the monitoring software as a service, validates it, hosts it, backs it up, secures it and releases new versions. Its hosting provider is a subcontractor you should know about.

The service provider or installer. Supplies and installs the sensors and gateways, qualifies them (IQ and OQ), configures the system with you and supports it. It may act for the platform supplier as an authorised partner.

The calibration laboratory. Calibrates the sensors traceably to national or international standards, as EU GDP 3.3 expects, and issues the certificates. Where you need accredited calibration, it should be accredited to ISO/IEC 17025 for that measurement and range. It may be part of the service provider or a subcontractor of it.

Each role can sit with a different company, or several with one group. With JTF and Sematics, one group covers the platform, the installation and support, and the calibration, so you have one point of contact; the roles still need writing down, because an inspector asks who did what. You can cover the roles in one agreement signed by all parties, or in separate agreements that fit together. Either works if no activity falls between them. If a contract acceptor passes work to a third party, GDP 7.3 and GMP 7.11 expect your prior evaluation and approval of the arrangement, and GDP 7.3 also an audit of the third party by you or the contract acceptor. For a wholesaler, approving subcontracted activities is one of the Responsible Person's duties (GDP 2.2 (vii)).

Who does what

A responsibility matrix for a monitoring system

The matrix is the heart of the agreement. This is a typical allocation for a cloud platform with a separate installer and calibration laboratory. R is responsible (does the work), A is accountable (approves and owns the outcome, one party per row), C is consulted (provides input or support) and I is informed. Adjust it to your arrangement, and check that every row has exactly one A and at least one R. Where a supplier is A, it is accountable for doing that activity within its own quality system; your accountability there is assessing the supplier and approving your reliance on it, and overall responsibility stays with you.

What to cover

What the agreement should cover

Annex 11 in force asks for clear statements of responsibilities but does not list the contents. The 2025 draft does: clause 7.5 lists nine things a contract with a service provider should cover. Even before it is adopted it is a useful checklist, and much of it is already expected under GMP chapter 7, Annex 11 clause 3 and MHRA data integrity guidance 6.20. Together with MHRA's data integrity guidance and PIC/S PI 041-1, the agreement should cover:

• The activities and documentation each party provides: the supplier's validation summary, IQ and OQ reports, calibration certificates, release documentation (draft 7.5 i).
• The procedures and regulatory requirements each party works to (draft 7.5 ii; GMP 7.5).
• Reporting and oversight: service levels, KPIs, response and resolution times, regular and incident reports (draft 7.3 and 7.5 iii).
• Audit: your right to audit before the work starts, on change, at a frequency based on risk and, under GDP 7.2, "at any time" (draft 7.5 iv; GMP 7.17).
• Support during regulatory inspection (draft 7.5 v; GMP 7.13).
• Resolution of issues raised in operation, audits and inspections, with CAPA and dates (draft 7.5 vi).
• Quality and security issues: what is notified, to whom and how fast, including data integrity failures at the supplier (draft 7.5 vii; PIC/S PI 041-1, 10.3.2).
• Exit: how you keep control of your data when the contract ends (draft 7.5 viii; MHRA DI 6.20).
• Release of new versions, and your possibility to test them before release (draft 7.5 ix).
• Data: ownership, location, retention, access for you and for inspectors, backup, restoration to the validated state and tested business continuity (MHRA GxP data integrity guidance, 6.5 and 6.20).
• Subcontracting: none without your prior written approval and an audit of the third party, with the same obligations passed down (GDP 7.3; GMP 7.11).

The 2025 draft

What the July 2025 Annex 11 draft adds for agreements

The European Commission and PIC/S published a revised Annex 11, with a revised Chapter 4 and a new Annex 22 on artificial intelligence, for consultation on 7 July 2025; the consultation closed on 7 October 2025. The drafts are not in force and may change. On 18 October 2026 the European Commission's EudraLex Volume 4 page still listed the 2011 Annex 11, so the 2011 text applies until the final version is published and its date of coming into operation has passed. In Great Britain, a revised Annex 11 applies only once the MHRA adopts it. Our page on the Annex 11 and Annex 22 drafts covers all three.

For agreements, the change is in section 7 of the July 2025 consultation draft of Annex 11, "Supplier and Service Management". Where the 2011 Annex 11 asks for formal agreements with "clear statements of the responsibilities of the third party" (3.1), the draft spells out what the contract should contain and how you oversee the provider:

Releases and changes

Change control: what you are told, and when

A cloud platform changes under you. GMP 7.12 says the contract acceptor "should not make unauthorized changes, outside the terms of the Contract", and Annex 11 clause 10 requires changes, including configuration changes, to be made "in a controlled manner in accordance with a defined procedure". The agreement turns that into specifics.

Ask how the supplier classifies releases. A useful split is: major releases that change validated behaviour of a function you rely on, notified in advance with the release notes, change records, verification evidence and an assessment against your configuration; minor releases that change nothing you rely on, documented after deployment; corrective and emergency releases for defects and security issues, verified and documented within days. Agree the notice periods and how you can assess or test a major release before it reaches you.

Configuration changes are a separate stream. Whoever makes them, they should be made only on a request approved under your procedure and recorded with a reason in the audit trail. Your change control then decides whether any qualification is repeated.

When something goes wrong

Deviations, incidents and notification times

GDP 7.3 says the contract acceptor "must forward any information that can influence the quality of the product(s)". Annex 11 clause 13 requires all incidents to be reported and assessed, with root cause and CAPA for critical ones. PIC/S PI 041-1 10.3.2 adds a requirement "to notify the contract giver of any data integrity failures identified at the contract acceptor site".

Put a time against each kind of event: the system unavailable or alarms not being sent; a deviation that may affect your records or notifications; a data integrity failure; a security incident or personal data breach; a calibration result found outside tolerance; and the loss of an accreditation or certification you rely on. For each, say who notifies whom, how fast, and what the notice contains. Route alarm outages to someone who answers out of hours, with your Responsible Person or quality lead in copy, and require the supplier to monitor its own alarm and notification pipeline around the clock.

One scenario inspectors probe: a gap in communication, so no alarms reach anyone while a fridge goes out of range. The cause is far more often a site network, a gateway losing power or a mobile signal drop than the platform itself, and every cloud service has planned maintenance. Good systems close the gap by design: sensors store their readings locally and upload them when the link returns (Sematics Node+ sensors hold up to 100 days). The agreement should say that readings recovered after any gap are checked against the alarm limits, that an excursion found is raised as a late alarm and notified to you, and that your alternative monitoring covers the gap while it lasts.

Your records

Data ownership, retention and the way out

MHRA expects contract givers to include "data ownership, governance and accessibility" in any contract or technical agreement with a third party (data integrity guidance 6.5). For cloud services it lists what to understand: "ownership, retrieval, retention and security of data", the physical location of the data and the laws that apply there, timely access to data, metadata and audit trails for you and for the authorities, archiving and readability for the whole retention period, restoration to the original validated state, and business continuity "included in the contract, and tested" (6.20).

Set the retention period from your own regulations, not the supplier's default; for GDP it is at least five years (EU GDP 4.2). Agree the backup frequency, recovery objectives and how often restoration is tested. Then write the exit: a complete export, including the audit trail and the full history of every alarm and investigation, in documented formats, a period of read-only access to check it, and written confirmation of deletion. Ask what happens to your records if the supplier stops trading.

Oversight

Audits, inspections and periodic review

GDP 7.2 asks for an audit of the contract acceptor before the work starts and whenever it changes, at a frequency based on risk, and says "Audits should be permitted at any time". Annex 11 3.2 bases the need for a supplier audit on a risk assessment, and 3.4 expects the supplier's quality system and audit information to be available to inspectors on request. GMP 7.13 reminds contract acceptors that their work may be inspected.

The agreement should also say how the parties support you at an inspection: how fast records are produced, and who is available to explain the system. Review the agreement itself on a schedule (two years is common) and whenever the service, the parties or the rules change; GMP 7.7 expects you to monitor and review the contract acceptor's performance.

ISPE GAMP 5 (second edition, 2022), the industry guide many validation teams use, describes in general terms how a regulated user can draw on supplier activities and documentation in proportion to risk, rather than repeating them. The agreement is what makes that reliance auditable.

Before you sign

What to check before signing

Read the agreement against your own process, not just against the template it came from.

• Every row in the matrix has one accountable party and at least one responsible party.
• The documents you will rely on for your validation are named, with when you receive them.
• Notification times exist for alarm outages, deviations, data integrity failures, security incidents and out-of-tolerance calibrations.
• Release classes, notice periods and your chance to assess a major release are written down.
• The data location, retention period, backup and restore testing, and exit export are specific.
• Audit rights include audits for cause, and do not restrict audits that GDP 7.2 says should be permitted at any time.
• Subcontractors are listed, including the hosting provider and any partner calibration laboratory, with their accreditation.
• The quality agreement prevails over the commercial terms on quality matters, and does not try to set liability.
• Signatories include each party's quality function, not only commercial signatories.

Common gaps

Where agreements usually fall short

Gaps we commonly see:

• Commercial terms used as the quality agreement. A subscription contract with an uptime figure says nothing about change control, deviations or data integrity.
• Two agreements that leave a gap. One with the software supplier, one with the installer, and nobody responsible for configuration, alarm testing or user training.
• Calibration not covered. No statement of traceability, accreditation scope, or who tells you when a sensor was found out of tolerance.
• No exit. Data "available on request" with no format, timescale or audit trail.
• Unseen subcontractors. A hosting provider or calibration partner nobody evaluated or approved.
• A supplier's validation pack treated as your validation. MHRA says vendor-supplied validation data accepted "in isolation" from your configuration and intended use is not acceptable (data integrity guidance 6.19). You still own your URS, configuration and PQ.

How we do it

How it works with JTF and Sematics

For GxP customers, Sematics, the platform supplier, puts a quality and technical agreement (QTA-01) in place with the customer. It names JTF as the service delivery partner, acting for Sematics under a written partner authorisation for the installation, calibration, configuration and qualification work the customer contracts for. It follows the same allocation as the matrix above: Sematics validates and maintains the platform; JTF supplies, installs and qualifies the hardware and calibrates the temperature sensors in our UKAS accredited laboratory (No. 10723), with other quantities calibrated by an approved partner laboratory, all with the customer approving; and the customer owns its requirements, configuration, PQ and procedures.

Our service agreement sits alongside it and sets out support, calibration and response times. QTA-01 is available on request to customers and prospective GxP customers; ask us for a copy. For how the validation is split, see validating your monitoring system.