Skip to main content
EudraLex Volume 4 Annex 11 is the European regulatory guideline governing computerised systems in GMP-regulated pharmaceutical manufacturing. It is issued by the European Commission and forms part of the EU GMP framework.

​
Seal’s approach to Annex 11

Seal is purpose-built for GxP-regulated environments—including GMP, GLP, and GCP. Compliance is not a bolt-on feature; it is embedded in the platform’s architecture. Pharmaceutical, biotech, and medical device companies trust Seal to meet Annex 11 requirements for computerised systems.
Key Annex 11 capabilities built into Seal:
  • Immutable, time-stamped audit trails that preserve all previous data
  • Electronic signatures with identity verification at signing
  • Role-based access control with granular permissions
  • Complete data retention with full audit history preserved
  • Automated backup with geographic redundancy
  • Change control via formal Change Sets with approval workflows
Annex 11 complements 21 CFR Part 11 (FDA’s U.S. regulation). Organizations operating in both jurisdictions can use Seal to satisfy both sets of requirements.

​
General

Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality.
Seal supports risk-based validation through configurable review requirements and formal Change Sets. Risk assessments can be documented within the platform, and validation effort can be scaled based on system criticality and GxP impact.
There should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT.
Seal provides role-based access control that maps to organizational structures. Permissions can be configured for Process Owners, System Owners, QA, and IT personnel with appropriate access levels for each role.
When third parties are used to provide, install, configure, integrate, validate, maintain, modify or retain a computerised system, formal agreements must exist.
Seal provides formal service agreements and validation documentation. Seal maintains SOC 2 Type II certification, and the platform is hosted on Google Cloud Platform (also SOC 2 Type II, ISO 27001 certified). Supplier qualification documentation is available upon request.

​
Project phase

The validation documentation and reports should cover the relevant steps of the life cycle.
Seal provides a comprehensive validation package including:
  • Validation Master Plan template
  • User Requirements Specification template
  • Functional Specification
  • Risk Assessment framework
  • Installation and Operational Qualification documentation
  • Validation Summary Report (generated on-demand)
The platform is validated by Seal following GAMP 5 2nd Edition principles. Configuration validation is performed collaboratively with each customer.
Computerised systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data.
Seal implements input validation rules including format checks, range validation, required field enforcement, and referential integrity checks. Data imports from external systems are validated against defined schemas before acceptance.
For critical data entered manually, there should be an additional check on the accuracy of the data.
Seal supports configurable review requirements for critical data. Dual-entry verification, approval workflows, and mandatory review steps can be configured based on data criticality.
Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period.
All data is stored on Google Cloud Platform with SOC 2 Type II and ISO 27001 certifications. Data is encrypted at rest and in transit. Automated backups are performed with geographic redundancy. Data remains accessible throughout the retention period (minimum 3 years beyond subscription).
It should be possible to obtain clear printed copies of electronically stored data.
Records can be exported as PDF documents including complete audit trails, signatures, timestamps, and annotations. Exports are formatted for regulatory inspection and submission.

​
Operational phase

Consideration should be given to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated “audit trail”). The reason for the change should be documented. Audit trails need to be available and convertible to a generally intelligible form.
Seal automatically generates immutable, server-timestamped audit logs for every action—including record creation, edits, status changes, signatures, and deletions. Change Sets provide a mechanism to document the reason for changes. Previous versions are preserved in full; no information is ever obscured. Audit logs are retained for the lifetime of the record and can be exported in human-readable format.
Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.
All configuration changes in Seal are managed through formal Change Sets. Each Change Set requires defined review and approval before changes go live. The complete history of all changes is recorded in the audit trail with full traceability.
Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP.
Seal runs automated validation tests continuously. Results are visible in the Validation tab within the platform. Customers can supplement these with their own automated configuration tests using Seal’s scripting engine.
Physical and/or logical controls should be in place to restrict access to computerised systems to authorised persons. Suitable methods of preventing unauthorised entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, restricted access to equipment and data storage areas.
Seal implements:
  • Unique user authentication (email + password or SSO)
  • Two-Factor Authentication (TOTP)
  • Role-based access control with granular permissions
  • Session timeouts (15-minute default for GxP compliance)
  • Rate limiting and automatic lockout after failed login attempts
  • IP-based access restrictions
  • SSO integration with enterprise identity providers (Azure AD, Okta)
All incidents, not only system failures and data errors, should be reported and assessed.
Seal maintains 24/7 monitoring with automated alerting for system issues. Incident response procedures are documented and tested. Customers are notified of any incidents affecting their data or system availability. A formal incident log is maintained.
Electronic records may be signed electronically. Electronic signatures are expected to have equivalent legal standing to handwritten signatures within EU, and be permanently linked to their respective record.
Electronic signatures in Seal display the signer’s full name, date/time (server-generated), and signature meaning. Signatures are immutably linked to their records and cannot be modified, removed, or transferred. At the point of signing, users must re-authenticate with their credentials to confirm identity.
When a computerised system is used for recording certification and batch release, the system should allow only Qualified Persons to certify the release of batches.
Seal’s permission system can restrict batch release actions to designated Qualified Persons. Electronic signatures for batch release capture the signer’s identity, timestamp, and signature meaning in the immutable audit trail.
For the availability of computerised systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown.
Seal is deployed with high availability architecture on Google Cloud Platform. Automated failover, geographic redundancy, and continuous backups ensure business continuity. A formal Disaster Recovery Plan is maintained and tested. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) details are available upon request.
Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant changes are to be made to the system, then the ability to retrieve the data should be ensured.
Archived records remain fully accessible in the database with complete audit trail history. Data integrity is maintained through immutable audit trails and database-level protections. Archived data can be retrieved at any time and remains readable in human-intelligible format.

​
Glossary

For definitions of terms used in Annex 11, refer to the EudraLex Volume 4 Glossary.