Inspectors from the Saudi Food and Drug Authority do not open an inspection by asking for your validation master plan. They ask to see a batch record, a laboratory result or a release decision, and then they ask who changed what, when, and why. Computerised systems are the place where those questions get answered or fail to be. This article walks through what the SFDA Guide to GMP expects of them, clause by clause, and what we would have ready before the inspector arrives.
The text we work from is the SFDA Guide to Good Manufacturing Practice, version 4.4, whose revision table dates the update to 21 May 2026 (SFDA GMP Guideline V4.4, PDF). Annex 11 of the guide, "Computerised Systems", is the one that matters here. Its wording is the same as the 2011 EU Annex 11 (EU text), which is why an inspection preparation built on Annex 11 travels well between the EU and Saudi Arabia.
SFDA, PIC/S and what it changes in an inspection
PIC/S lists the SFDA as its 56th Participating Authority, from 1 July 2023. The Saudi application went in in February 2020, followed by a paper assessment and an on-site visit in March 2023, and the PIC/S Committee accepted it unanimously in May 2023 (PIC/S announcement).
PIC/S does not tell us how an SFDA inspector will behave on a Tuesday morning, and we will not pretend it does. What we can say is how we read it. An inspectorate that has been assessed against the PIC/S expectations for inspection systems tends to inspect the way other PIC/S inspectorates inspect: it follows data, not documents, and it expects the same data integrity discipline you would show a European or other PIC/S inspector. If you already run a site that would pass an inspection by one PIC/S authority, you are not starting from zero. If your computerised systems rely on exceptions that a European inspector would not accept, assume Riyadh will not accept them either.
What Annex 11 asks for, clause by clause
The principle of the annex is blunt. The application should be validated, the IT infrastructure should be qualified, and where a computerised system replaces a manual operation there should be no decrease in product quality, process control or quality assurance and no increase in overall risk. Everything else hangs from that.
Clause 1: Risk management
Risk management applies throughout the lifecycle, taking into account patient safety, data integrity and product quality. Decisions on the extent of validation and data integrity controls must rest on "a justified and documented risk assessment". The inspector's question is simple: show me the assessment that decided why this module got full testing and that one got a lighter touch.
Clause 3: Suppliers and service providers
Formal agreements must exist with any third party that provides, installs, configures, integrates, validates, maintains (including by remote access) or modifies a system, and they must state the third party's responsibilities. Clause 3.3 asks regulated users to review the documentation that comes with commercial off-the-shelf products against their own user requirements, and 3.4 says that quality system and audit information on suppliers or developers of software must be available to inspectors on request. If your vendor will not let you pass that information on, you have a problem on inspection day, not a procurement preference.
Clause 4: Validation
This is the longest clause. The documentation should cover the relevant lifecycle steps and include change control records and reports on deviations observed during validation (4.1, 4.2). You need an up to date inventory of GMP systems (4.3) and, for critical systems, a system description showing physical and logical arrangements, data flows, interfaces and security measures. User requirements must be based on documented risk assessment and GMP impact and be traceable throughout the lifecycle (4.4). Test evidence should show that parameter limits, data limits and error handling were considered (4.7), and any data migration must be validated so that values and meaning are not altered (4.8).
Clauses 5 and 6: Data checks and accuracy checks
Systems that exchange data electronically need built-in checks for correct and secure entry and processing (5). Critical data entered manually needs an additional accuracy check, by a second operator or by validated electronic means (6). If a validated interface can do it, the guide expects you to use it; if people retype, expect to be asked who checked and how that check is evidenced.
Clause 9: Audit trails
The clause says that, based on risk assessment, consideration should be given to recording all GMP-relevant changes and deletions; for a change or deletion of GMP-relevant data the reason should be documented; and audit trails "need to be available and convertible to a generally intelligible form and regularly reviewed". The last three words are where inspections are won and lost. Having an audit trail switched on is the easy part. Inspectors ask for the procedure that defines who reviews it, how often, what they look for, and the last three review records. A system that captures everything and a quality unit that has never opened the log will be cited together.
Clause 10: Change and configuration management
Any change, including system configuration, is made in a controlled manner under a defined procedure. A changed calculation factor, a new user role or an edited specification limit in a LIMS is a configuration change, and an inspector will compare the system's current settings with your last approved configuration record.
Clause 11: Periodic evaluation
Systems should be periodically evaluated to confirm they remain valid and GMP-compliant. The evaluation should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.
Clause 12: Security
Access is restricted to authorised persons by physical or logical controls, with the extent depending on criticality (12.1, 12.2). Creation, change and cancellation of access authorisations should be recorded (12.3), and data and document management systems should record the identity of operators entering, changing, confirming or deleting data, with date and time (12.4).
Clause 13: Incident management
All incidents, "not only system failures and data errors", should be reported and assessed, and the root cause of a critical incident should drive corrective and preventive action. If your incident log for the LIMS contains only outright outages, an inspector will wonder who decides what is reportable.
Clause 14: Electronic signatures
Electronic records may be signed electronically. A signature is expected to have the same impact as a handwritten signature within the company, to be permanently linked to its record, and to include the time and date it was applied. In practice inspectors test the link: sign a record, change a field, and see what the system does with the signature.
Clause 15: Batch release
When a computerised system records certification and batch release, it should allow only Qualified Persons to certify, clearly identify and record the person releasing or certifying, and do so using an electronic signature. Clause 8.2 adds that for records supporting batch release it should be possible to print copies showing whether any data have changed since original entry.
Clause 16: Business continuity
For systems supporting critical processes, provisions must exist to continue those processes in a breakdown, for example a manual or alternative system. The time to bring the alternative into use should be based on risk, and the arrangements "adequately documented and tested". Tested is the operative word. A downtime SOP that has never been exercised is an assumption, not a provision.
Clauses 7 and 17: Data storage and archiving
Data must be secured physically and electronically, checked for accessibility, readability and accuracy, and remain accessible throughout the retention period. Backups are regular, and the ability to restore is checked during validation and monitored periodically (7.2). Archived data should be checked for accessibility, readability and integrity, and if the system changes, the ability to retrieve the data must be ensured and tested (17).
Chapter 4 record-keeping that touches your systems
Annex 11 is not read alone. Chapter 4 of the SFDA guide, Documentation, says documents may exist as paper, electronic or photographic media, and that "records include the raw data which is used to generate other records". For electronic records, regulated users should define which data are raw data, and "at least, all data on which quality decisions are based should be defined as raw data".
Clause 4.1 acknowledges hybrid forms, part electronic and part paper, and requires that relationships and control measures for master documents, official copies, data handling and records be stated for both hybrid and homogeneous systems. Clause 4.8 says records should be made at the time each action is taken, in a way that makes all significant activities traceable. Clause 4.10 requires that it be defined which record relates to each manufacturing activity and where it is located, with controls that ensure integrity throughout the retention period, validated where appropriate. Batch documentation must be kept for one year after batch expiry or at least five years after certification by the Qualified Person, whichever is longer (4.11). Other documentation follows the business activity it supports; critical documentation including raw data supporting the marketing authorisation is kept while the authorisation remains in force (4.12).
If you make active substances, the same guide carries its own computerised systems section in Annex 18 (section 5.4). It asks for validated systems, controls against unauthorised access and omissions, a record of any data change with the previous entry, who changed it and when, and for incidents to be recorded and investigated.
A cautious note on Saudi data protection law
This is not legal advice, and it does not say that GMP records must stay in the Kingdom. The Saudi Personal Data Protection Law applies to personal data, and audit trails, user accounts and signatures do carry names. The SDAIA guide to the law states that transfers of personal data outside the Kingdom are subject to additional requirements under the law and its Implementing Regulations, and that an organisation planning such a transfer should review Article 29 and the regulations, including the effect on national security and vital interests and whether only the minimum necessary data is transferred (SDAIA, Guide to the Saudi PDPL). If a cloud-hosted GMP system or a vendor's remote support sits outside the Kingdom, take the question to your counsel and your data protection officer before you sign the contract.
Readiness checklist
- An inventory of every GMP computerised system, including standalone instrument PCs, with a GMP-impact note for each (4.3).
- A system description for each critical system: data flows, interfaces, security measures (4.3).
- A documented risk assessment that explains the depth of validation (1, 4.1).
- Requirements traceable to test evidence, with error handling and limits tested (4.4, 4.7).
- Supplier agreements naming responsibilities, remote access included, and supplier audit information you can hand to an inspector (3.1, 3.4).
- A written definition of raw data for each electronic system (Chapter 4).
- An audit trail review SOP and the last three completed reviews (9).
- The current configuration matched to the last approved change record (10).
- A periodic evaluation report that mentions deviations, incidents and upgrades, not just "no change" (11).
- An access list reconciled against HR leavers and role changes, with no shared accounts (12).
- An incident log that includes near misses, with root cause on the critical ones (13).
- An electronic signature test showing the signature stays linked to the record (14).
- A release workflow that restricts certification to the Qualified Person and can print changes since original entry (8.2, 15).
- A downtime procedure that has actually been exercised (16).
- A restore test for backups and a retrieval test for archived records (7.2, 17).
Where software helps
Software does not replace the procedures above, but it removes some of the manual evidence work. CORPEX builds LIMS for SFDA-regulated laboratories, an eQMS and electronic batch records as separate products. In our eQMS every GMP write goes into an append-only, hash-chained audit trail that stores the user, the time, the old and new value and the reason. CORPEX LIMS keeps a hash-chained audit trail, and in Corpex-EBR electronic signatures send the signer back through the identity provider to re-authenticate. The eQMS is installed on your own servers or private cloud. You still own validation, review and the SOPs around all of it.
Frequently Asked Questions
Does the SFDA apply EU Annex 11?
The SFDA Guide to GMP version 4.4 includes an Annex 11 titled Computerised Systems whose text matches the 2011 EU Annex 11. It covers risk management, suppliers, validation, audit trails, change control, security, incident management, electronic signatures, batch release, business continuity and archiving.
Is SFDA a PIC/S member?
Yes. PIC/S lists the SFDA as its 56th Participating Authority from 1 July 2023, after a membership application submitted in February 2020 and an on-site visit in March 2023.
Must audit trails be reviewed?
Annex 11 clause 9 says audit trails need to be available, convertible to a generally intelligible form and regularly reviewed. Inspectors usually ask for the review procedure and recent review records.
Who may certify batch release in a computerised system?
Clause 15 says the system should allow only Qualified Persons to certify the release of batches, clearly identify and record the person certifying, and use an electronic signature.
How long must batch records be kept?
Chapter 4 clause 4.11 requires batch documentation to be kept for one year after expiry of the batch or at least five years after Qualified Person certification, whichever is longer.
Sources
- SFDA, Guide to GMP, version 4.4: Annex 11, Chapter 4, Annex 18 section 5.4
- European Commission, EudraLex Volume 4, Annex 11 (2011)
- PIC/S, Bulgaria BDA and Saudi Arabia SFDA join PIC/S
- SDAIA, Guide to the Saudi Personal Data Protection Law, December 2023
Preparing for an SFDA inspection?
See how CORPEX software supports audit trails, e-signatures and QP release for Saudi pharma manufacturers.
Explore the Saudi eQMS page