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. Product Quality

Incident Procedure

Last updated 21 days ago

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 , and our .

Detection

Seal’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.

Communications

Effective 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 Debugging

The 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.

Resolution

Once 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.

Data Backup and Disaster Recovery
Disaster Recovery Plan