1. Introduction
1.1 Purpose
This Release Lifecycle Policy (the "Policy") governs the development, testing, validation, and deployment of software changes to Scispot’s lab management and data integration platform. It ensures that all releases are executed in a controlled, repeatable, and auditable manner, balancing the agility of bi-weekly sprints with the rigorous validation required for releases in regulated environments. The Policy mandates compliance with SOC 2, HIPAA, and 21 CFR Part 11 standards, safeguarding security, data integrity, and regulatory adherence.
1.2 Scope
This Policy applies to all software modifications—including new features, enhancements, bug fixes, and configuration updates—across Scispot’s platform, whether deployed to non-regulated or regulated environments. Releases intended for regulated environments, such as those requiring GMP compliance, are subject to additional validation in a sandbox environment within a validated cloud infrastructure.
2. Roles and Responsibilities
The following roles are explicitly defined to ensure accountability and clarity:
Developers: Implement changes within bi-weekly sprints, perform unit testing, and maintain the change log with detailed entries.
Testing Team: Conduct integration and system testing, document results, and confirm compliance with acceptance criteria.
Validation Team: Execute validation for releases in regulated environments, including User Acceptance Testing (UAT) and compliance testing, within the sandbox environment.
Compliance Team: Oversee adherence to SOC 2, HIPAA, and 21 CFR Part 11, maintain audit trails, and approve compliance-related documentation.
Deployment Team: Manage deployment to sandbox and production environments, execute rollback procedures if necessary, and verify post-deployment stability.
Change Control Board (CCB): Review and authorize all changes, with heightened scrutiny for releases in regulated environments, ensuring alignment with business needs and regulatory obligations.
3. Development Process
3.1 Bi-Weekly Sprints
Software changes shall be developed in fixed, bi-weekly sprint cycles. (except GMP workflows that takes longer cycles via customer reviewed "Sandbox" environment)
Each sprint shall commence with a planning session to define objectives, deliverables, and acceptance criteria, documented in Scispot’s designated sprint management system.
Developers shall complete assigned tasks within the sprint timeframe, adhering to secure coding practices per SOC 2 requirements.
3.2 Change Log
Every change—without exception—shall be recorded in a change log maintained in a version-controlled repository. Entries must include:
A precise description of the change (e.g., "Added integration for instrument X").
The purpose of the change (e.g., "To enhance data capture for compliance with CFR Part 11").
The developer’s identity and timestamp of implementation.
The change log shall be immutable, accessible to authorized personnel, and retained as part of the audit trail.
Change log will be part of the product that customers can access every other Monday of the week.
4. Testing Process
4.1 Standard Testing for All Releases
All changes, regardless of scope, shall undergo the following mandatory testing:
Unit Testing: Performed by the developer to verify individual components. Results shall be logged in Scispot’s test management system.
Integration Testing: Conducted by the testing team to ensure interoperability of components. Test cases and outcomes shall be documented.
System Testing: Executed to validate the end-to-end functionality of the platform. Results must confirm that all acceptance criteria are met.
4.2 Validation for Releases in Regulated Environments
Changes intended for regulated environments (e.g., GMP-compliant labs) shall undergo additional validation in a sandbox environment that mirrors the production setup.
The Validation Team shall perform User Acceptance Testing (UAT) with predefined test scripts that cover all critical workflows.
Compliance testing shall verify adherence to 21 CFR Part 11, including electronic signatures, audit trails, and data integrity controls.
All validation activities shall be documented, reviewed, and approved by the Compliance Team before deployment.
5. Deployment Process
5.1 Sandbox Deployment
All changes shall first be deployed to the sandbox environment for validation.
The Deployment Team shall verify the stability and performance of the changes in sandbox before proceeding.
5.2 Production Deployment
Upon successful validation, changes shall be deployed to production during a scheduled maintenance window.
The Deployment Team shall monitor the deployment and execute rollback procedures if any issues are detected.
Post-deployment, the Testing Team shall perform smoke tests to confirm functionality.
6. Documentation and Training
All processes, test results, and validation activities shall be documented in accordance with SOC 2 and HIPAA requirements.
Training shall be provided to relevant personnel on new features and compliance obligations.
7. Policy Review and Updates
This Policy shall be reviewed annually or upon significant regulatory changes.
Updates shall be approved by the CCB and communicated to all stakeholders.