Release Communication and Validation for Customers

Required Roles: All

Required Permissions: N/A

Introduction

This article explains how Kivo performs and communicates software releases, what customers can expect for each release type, and how releases may impact customer validation and change control activities. As we continue to enhance our platform, we want to make it easy for customers to plan ahead, maintain compliance, and understand exactly what changes are being introduced and when.

Overview

Kivo follows a controlled, risk-based release process designed to deliver new functionality into your hands as quickly as possible, without compromising compliance or the validated state of the platform.

Customers can expect:

Predictable release communication for validation-relevant changes
Transparency into what is included in each release
Validation documentation to support audits and change control

Key concepts include:

Defined release types (Feature, Patch, Configuration)
Advance notification for feature releases
Feature flags to control major functionality
Validation documentation availability post-release

Release Types and Customer Impact

Kivo continuously improves the platform through regular, controlled releases designed to deliver incremental value while maintaining a validated state. To support transparency, compliance, and customer change control, releases are categorized by type so it is clear when customer-facing functionality changes versus when updates are limited to fixes or system configuration. This approach allows customers to easily understand impact and plan validation activities appropriately. The three types of releases are Feature Releases, Patch Releases, and Configuration Releases. Click each of the dropdowns below to learn more about each release type.

Feature Releases

Feature releases introduce new customer-facing functionality and undergo full validation by Kivo prior to production deployment.

What customers can expect:

Notification at least five (5) business days prior to release
A clear release announcement outlining scope and risk
Validation documentation uploaded to customer environments after release

Feature releases may include minor or major features:

Minor features do not impact workflows, SOPs, or compliance requirements and may be enabled by default.
Major features may require retraining, SOP updates, or impact regulatory requirements and are disabled by default using feature flags.

Customers control when major features are enabled, allowing time for internal review and validation planning.

Patch Releases

Patch releases include bug fixes, performance improvements, or minor usability updates that do not introduce new functionality.

What customers can expect:

No advance release notification
No workflow or functional changes
Minimal to no validation impact

Supporting documentation is available post-release for transparency and audit purposes.

Configuration Releases

Configuration releases update system settings without changing application code.

What customers can expect:

No new functionality
Low validation risk
No required customer action

These releases are used to improve performance, stability, or infrastructure and do not affect user workflows.

Release Communication Timeline

When Customers Are Notified

For feature releases, customers are notified at least five business days before the release. This timeframe is intentionally designed to support customer change control processes, internal reviews, and validation planning.

Patch and configuration releases do not require advance notification due to their limited scope and low risk.

How Customers Know What’s Included

Each feature release includes a structured release announcement that clearly defines the release scope. The announcement includes:

Release version and planned timing
A complete list of features included in the release
A high-level summary of changes
A risk assessment highlighting potential validation or process impact

Once the release announcement is published, the feature scope is finalized and will not change prior to deployment. Customers can rely on this information when performing impact assessments or preparing change control documentation.

Validation and Documentation

Kivo performs validation activities appropriate to the scope and risk of each release. Depending on release type, this may include:

Change Control documentation
Operational Qualification (OQ) testing
User Acceptance Testing (UAT)
Validation Summary Reports
Certificates of Validation (feature releases only)

After release, all applicable validation documentation is uploaded to customer environments. Customers can use this documentation to:

Support internal change control
Respond to audits
Demonstrate ongoing compliance

Because Kivo is a cloud-based, multi-tenant platform, customers do not need to perform installation qualification (IQ).

Feature Flags and Customer Control

To support customer readiness and compliance:

Minor features may be enabled automatically if they do not impact existing processes or compliance
Major features are disabled by default and enabled only after customer review
Any exception requiring mandatory enablement is communicated at least 30 days in advance, with sandbox access provided when applicable

This ensures customers remain in control of when validation-impacting changes enter their production environment.

What Customers Do (and Don’t) Need to Do

In most cases, releases require little to no action on your part. Kivo manages development, validation, and deployment to maintain the platform’s validated state while keeping you informed of any meaningful changes.We encourage customers to take a risk-based approach when documenting their review of release materials, ensuring the level of documentation is proportional to the release type.so what does it actually mean for you?

Customers typically do not need to:

Revalidate the entire system for each release
Perform installation qualification (IQ) activities
Take action for patch or configuration releases
Conduct additional testing for minor usability or performance updates

Customers may need to:

Review release announcements for feature releases
Evaluate internal SOPs, training materials, or workflows for major features
Leverage Kivo-provided validation documentation to support audits or change control

In short, most releases are designed to be seamless. When a release does require attention, you will receive advance notice and the documentation needed to confidently assess impact and maintain compliance.

Kivo Internal Procedures and Customer Transparency

Kivo maintains formal, quality-managed procedures that govern how software is developed, validated, released, and controlled to ensure the platform remains compliant and in a validated state. These procedures are designed to support regulatory expectations while enabling continuous improvement of the platform.

Current versions of the following procedures are available to customers at the bottom of this page:

Software Development (SOP-PD-100)
Describes how Kivo designs, builds, tests, and reviews software using a controlled development lifecycle, including code review, testing, and release readiness.
Change Control (SOP-PD-102)
Defines how all changes are documented, risk-assessed, reviewed, approved, and tracked to ensure changes to validated systems are implemented in a controlled and compliant manner.
System Validation (SOP-PD-101)
Outlines Kivo’s risk-based validation approach, including validation planning, testing, documentation, and approval activities required to maintain a validated state across releases.
Product Release (SOP-PD-103)
Describes how releases are planned, classified, validated, deployed, and communicated to customers, including release types, notification timelines, and validation documentation delivery.

Together, these procedures ensure that every release is developed and deployed using a consistent, compliant framework, while providing customers with the documentation and transparency needed to support their own validation and change control requirements.