Skip to main content
This page is a summary of the Quality processes in Seal. It briefly describes how Seal is developed and delivered to customers in line with software development best practices, especially those of GxP-regulated industries. Seal, designed for GxP-regulated industries, facilitates the creation, review, and maintenance of critical records and databases, as well as the capacity to process information rapidly. Seal upholds quality, reliability, and integrity across its systems, processes, and product that aligns with regulatory frameworks and international standards. Seal’s development lifecycle follows the principles of GAMP 5 2nd Edition, applying modern, agile development practices within a structured quality management framework. This “agile waterfall” approach allows for iterative development and rapid feedback while maintaining the rigor and traceability required for GxP systems. It is this tried and tested internal process that makes our new paradigm for GxP software not just possible, but reliable. Understand our quality practices:
This section is a summary of the Seal product development lifecycle. The product development and support phases are guided by the following requirements from GAMP Supplier Good Practices (but are not limited to):
  • Documented set of procedures and standards
  • Well-defined requirements from regulated companies before onboarding
  • Quality planning
  • Design review process
  • Defined standards for software production
  • Clear user documentation and training
A summary of the process is listed below.
  1. Scope
The objective of this stage is to scope issues and requirements, based on following criteria (but not limited to):
  1. Description of requirement, including user stories, user flows, and edge cases
  2. Source of requirement
  3. Level of priority
  4. Additional comments regarding analysis, possible solutions, problems, and queries
This comprehensive approach ensures structured documentation to allow clear, concise scoping plans.
  1. Specify
This converts the scoping conducted above into actionable items to address the issue or requirement. This includes (but not limited to):
  • Review and clarification meetings to define specifications
  • Developing designs based on requirements, with design iterations if necessary
  • Creation of issues for approved designs
This involves collaborative work between the development, design, and product delivery teams.
  1. Develop
GitHub serves as Seal’s designated task system for creating, tracking, and managing work tasks. This centralised platform proves advantageous for software teams in GxP environments due to features, including version control with auditing capabilities, change tracking and documentation, automated testing and continuous integration tools, and efficient issue tracking.Per Appendix D4 of GAMP 5 on the Management of Software, the following requirements for each software task ensure clear traceability and are all available in GitHub:
  1. Reference/traceability to associated design artefacts
  2. Descriptions of the task
  3. Timestamps
  4. Summary of changes
  5. User account making changes
The timeframe for issues are based on the priority assigned to the requirement.
  1. Testing
A rigorous multi-phase testing process is conducted before any new feature or update is introduced to ensure the platform maintains the highest standards of quality, performance, and reliability for users.Production changes undergo stringent testing prior to release. Our comprehensive approach includes multiple layers of automated testing (including unit, integration, and end-to-end tests) as well as manual peer reviews.A crucial aspect is the integration of Continuous Integration, where automated checks are performed with each commit. This ensures immediate notification to the developer in case of errors, maintaining a proactive approach to identifying and addressing issues during the development lifecycle. Additionally, if applicable, additional tests are written for changes introduced by the new features to test for any specific interactions and flows that are affected by the new changes.For all changes, it is mandatory that:
  • All pull requests must pass automated tests
  • All pull requests require the completion of a peer review and approval
  1. Release
Release would entail passing of all requests, complete QA checks, successful validation of the platform.Feature descriptions are documented on in the Seal Changelog.Executed platform tests documented in the ‘Validation’ tab in your Seal platform.
This section is a summary of Seal’s platform operation tests, guided by the requirements from GAMP5 Principles. GAMP5 guidelines provide a risk-based approach to testing for software operation, ensuring that systems perform as intended and comply with regulatory requirements.The following lists show a summary of the tests. Note that this is not a comprehensive list of all tests.Database
  • Adding, removing, and recovering user data
  • Archiving
  • Data cached and updated in browser
  • Adding, deleting, an tracking of changes in cards
  • Expected API end points and their documentation
  • Correct permission levels data
  • Sending and responding to requests
  • Roles
  • Database test enviroments correctly set up to run test suits
  • Integrity of versioned data and the functions that modify it
End-to-end
  • Creating and deleting orgs
  • Creating entities
  • Autosaving functions
  • Creating a draft from a published versions
  • Review flows with single and multiple reviewers
Stats, logs, and errors are monitored in the Google Cloud console.Seal maintains a variety of channels to monitor security incidents such as downtime or service disruptions. Learn more in our Incidence Procedure below.
Seal prioritizes proactive monitoring and swift response to ensure continuous, secure operations. To maintain high standards of service availability and resilience, a robust array of monitoring channels designed to detect potential security incidents, including downtime, service disruptions, and unusual system activities.This page briefly outlines the Incident Procedure for responding to, documenting, and resolving software downtime incidents. It does not delve into comprehensive details - for more details, see Data Backup and Disaster Recovery, and our Disaster Recovery Plan.DetectionSeal’s commitment to 24/7 monitoring enables Seal to provide a seamless user experience and uphold the security and integrity of the platform.Seal maintains a variety of channels to monitor security incidents such as downtime or service disruptions.Automated alerts are configured to trigger in response to specific thresholds. These alerts are customisable to align with Seal’s risk management criteria, addressing a range of scenarios, from routine service inconsistencies to critical security threats.Regular system audits and validation checks are conducted on all monitoring and alerting protocols. These tests ensure that each channel’s sensitivity, accuracy, and responsiveness remain effective over time. Additionally, incidents are simulated on a periodic basis, to assess alert accuracy and improve incident response times. These simulations allow the Seal Team to practice real-time responses.CommunicationsEffective communication is crucial for rapid response, clear information flow, and effective resolution.Communication during an Incidence procedure involves multiple stages, starting from the first responder’s actions, team notifications, the creation of dedicated communication channels, and continuous status updates. Each step is designed to ensure that all relevant stakeholders, both internal and external, remain informed and coordinated throughout the incident lifecycle.The various communication channels ensure that that Seal’s response teams can quickly share critical information, streamline decision-making, and maintain a transparent, coordinated approach to incident resolution.Assessment and DebuggingThe first responder, in collaboration with relevant engineers and team leads, evaluates the incident based on the following criteria (but not limited to):
  • User impact: Determine the scope of affected users or services - higher severity is assigned if a significant portion of users or core functions is impacted.
  • Service dependency: Assess which critical systems or components are affected and any downstream dependencies. Issues affecting core services, such as database security, are prioritised.
  • Recovery time: Consider the estimated time needed to resolve the issue.
Once severity is assessed, the technical team begins systematic debugging. This may include multiple steps, such as (but not limited to):
  • Information gathering: The team retrieves relevant logs, metrics, and alerts from monitoring systems to identify anomalies or error patterns.
  • Reproducibility: Where possible, the team attempts to replicate the issue in a controlled environment, to understand the conditions triggering the incident.
  • Identification of root cause
All information and findings are documented in the Incident Report.ResolutionOnce the issue has been clearly identified, the Seal team works to implement a resolution, to not only restore functionality but also to mitigate future occurrences. Once the fix is implemented, the team performs thorough testing to confirm that the issue is resolved, such as end-to-end testing.Relevant documentation, tests, and monitoring channels are updated to reflect findings and learning from the incident.

​
Change Management and Handling Risk

Every pull request making changes to our platform gets categorized into one of the following 4 risk levels. Each risk level has associated actions that will be carried out by Seal, to ensure that users have sufficient warning of any changes being introduced that may disrupt their workflow.
Risk LevelDescriptionAction
NoneNo functionality changes, no user facing changes to their workflow.No action required.
MinorMinor functionality change. There is a potential change to a user workflow but they do not need to change how they carry out work.Message to customers on release. Update docs, making the new behaviour explicit in detail.
SignificantThere will be changes to how a user carries out their work in Seal. E.g. a button to create instances is removed from a particular view.Message to customers at least 48h before release. Update docs, making the new behaviour explicit in detail.
MajorMajor functionality change. E.g. removing a feature.Message to customers at least 1 week in advance. Review and discussion with product leadership and customer team.Update docs, making the new behaviour explicit in detail.
⌘I