The Seal Platform
WebsiteGet StartedContact Us
The Seal Platform
  • Website
  • Contact Sales
  • Logging in & System Requirements
  • Get Started Here
  • Moving to Seal
    • Migration
    • Implementation
  • Manage
    • Where do I start?
    • Creating Types
      • Documents
      • Work Done
      • Files
        • Extracting Fields with AI
      • Scripts
        • Writing Scripts with the Seal Module
        • Script Action Buttons
      • Charts
      • Converting Between Types
    • Adding Content and Fields
      • Computed Titles
      • Formatting Text
      • Formulas
      • Numbered Lists
      • Setting Assignees
      • Setting Out-of-Specifications
      • Setting Review Requirements
      • Submission Tables
    • Executing Types: Test Instances
    • Work Instructions
    • Change Sets
    • Active Versions
    • Training
    • API
  • Operate
    • Where do I start?
    • Re-executing Instances
    • Reviewing
  • MISC
    • Glossary
    • Inbox
    • Search Page and Saved Views
    • User Permissions and Roles
    • Tags
    • Github Integration
    • Change Management
    • Seal Changelog
  • Video Guides
    • Creating Templates
    • Creating and Reviewing Instances
    • Sending and Completing Trainings
  • Validation
    • Why do I need to validate my platform?
    • What is needed from my end for validation?
    • How is my system validated?
      • Baseline Validation
      • Configuration Validation
      • Compliance Validation
      • What about IQ, OQ, or PQ?
      • Automatic Revalidation
        • Change Controls
      • How do I know if my system is compliant to a standard?
        • Setting up your System
        • Performing Compliance Validation
    • GxP Validation for enterprise customers
    • Can I download a Validation Report?
      • Software Functionality Verification
    • Common Validation FAQs
  • Product Quality
    • Seal's Guarantee of Quality
    • Product Development Lifecycle
    • Platform Operation Tests
    • Incident Procedure
  • IT & Security Policies
    • Seal's Tech Stack
    • Data Storage and Security
    • Cloud Servers vs On-Premises File Servers
    • Data Backup and Disaster Recovery
    • Disaster Recovery Plan
    • Handling Confidential Data
    • Common IT FAQs
  • Regulatory Standards
    • 21 CFR Part 11
    • EU Volume 4 Annex 11
    • ISO 13485 Medical Devices
    • Clinical Laboratory Improvement Amendments (CLIA)
  • Support
    • Contact us
Powered by GitBook

Copyright © Seal 2025. All Rights Reserved.

On this page
  1. Validation

Can I download a Validation Report?

Last updated 1 month ago

This validation report is applied to an unconfigured Seal Platform. This does not serve as legal counsel as a validation report for a customised platform.

In order for a complete validation of a customer system to occur, the customer must partner with the Seal Team to manage and testing any configuration they deem necessary, based on their intended use and associated risk.

For more information or to export this for your documentation, please reach out to our team at support@seal.run.

This Validation Plan aims to outline validation of the a basic, unconfigured Seal platform. This page outlines the validation scope, a risk-focused approach, necessary resources, and quality assurance tasks. Following this will achieve the outcome that Seal consistently operates as intended and maintains validated status across its life cycle, for an unconfigured platform.

1

Introduction and Context

Seal is an electronic platform. The tool is web based and multi-tenant, accessible on any device capable of supporting a web browser. Seal uses SaaS industry standard SDLC methodology and Agile software development.

While Seal is configurable to meet customer needs for quality system management, Seal does not do custom code or customise of features at the software code level for customers. All configuration is set in the individual customer instances.

Seal has an open API and is capable of pushing/pulling data to/from other software tools through integrations. In the case that a customer desires an integration to another tool, it is the customer's responsibility to define and document that interface, as well as test that the interface produces the desired behavior in Seal. Seal supports these activities as necessary, but ultimately Seal's functionality is designed for these activities and the behavior of the system is the same whether the data is input through integration or the standard user interface.

Seal is not directly responsible for the Patient Safety, Product Quality, or Data Integrity (specifically meaning systems that generate/control product quality or release data). In the case of data integrity specifically, the standard elements of access control, security, user management, privilege management, data backup and retention are already covered through the Risk Assessment.

2

Regulatory References

The use of Seal is subject to regulations prescribed by American and European regulatory agencies.

Seal is designed to support the common elements of all quality management processes generally considered by the Life Sciences industry and ISO 9001 (the basis for all quality management systems and ICH), and has the flexibility to support specifics as necessary at the customer level.

The customer is responsible for their individual regulatory compliance activities and their business process definitions/risk management.

3

Risk Assessment

Please refer to the Risk Assessment page.

4

Software Functionality Verification

Please refer to the page.

5

Recommended Operating System for Optimal Use

Opvia can be used across various operating systems such as Windows and MacOS.

Google Chrome is the recommended browser as it is the platform used to design and test Opvia. It is recommended that users upgrade to the latest version of Google Chrome for optimal performance.

6

Continuous Improvement Opportunities

Ongoing monitoring and evaluation are recommended to address any emerging issues and ensure sustained performance. Identified weaknesses or areas for improvement should be addressed through an internal feedback system, such as the incorporation of periodic user feedback or monthly calls with Skye Biologics’ Upper management.

7

Conclusion

Based on the conducted tests and analysis, it has been confirmed that the software successfully meets the specified functional requirements. The validation outcomes underscore the successful assessment of the software's functionality, reaffirming its suitability for its intended purpose in Skye Biologics. Users can have confidence in the software's ability to perform as expected, contributing to Skye Biologics’ objectives and user satisfaction.

Software Functionality Verification