Service Level Agreement
Definitions
| Term | Description |
|---|---|
| Availability Zone (AZ) | One or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. |
| Core Business Hours | 8am-6pm for the geography that the application instance is located in. |
| Customer | Refers to potential, past, or current customers. |
| Development | The development environment is the location of the main development activities for customizations to the application. This is where developers spend time functionally testing and improving the code that has been written to work with the application. Typically, a development environment meets the minimum system requirements for the application to function and are often housed on premise, for greater control and flexibility. |
| Demo/Sandbox | Environments which are used for demonstration and feature walkthrough purposes |
| Hosting | Hosting makes legacy applications and websites accessible over the internet, using cloud resources. |
| Minor Environments | Minor Environments are non-production environments. Environments with UAT/Staging, Quality Assurance (QA)/Test or Development classifications, that may have been sold at a reduced service/license rate |
| Production | Production is the fully supported, resilient application environment. It is ready to be used by end users, to carry out their activities. |
| QA/Test | An environment where tests can run uninterrupted. Tests can be for checking that new releases and or features have not broken any customizations or configurations made, or that new customizations developed work as expected with the final product. Typically, a test environment meets the minimum system requirements for the application to function and are often housed on premise, for greater control and flexibility. |
| Region | Separate geographic areas that AWS uses to house its infrastructure. These are distributed around the world so that customers can choose a region closest to them in order to host their cloud infrastructure there. |
| RPO | Recovery Point Objective – the maximum amount of data, as measured by time, that can be lost after a recovery from a disaster, failure, or comparable event before data loss will exceed what is acceptable to an organization. |
| RTO | Recovery Time Objective – the maximum tolerable length of time that a computer, system, network or application can be down after a failure or disaster occurs. |
| SaaS | Software-as-a-Service (SaaS) is a software licensing model, which allows access to a software application on a subscription basis, using a web browser. SaaS allows each user to access programs via the Internet, instead of having to install the software on the user’s computer. |
| SLA | Service Level Agreement |
| UAT/Staging | A UAT environment is set up for “user acceptance” of new functionality, along with testing how new customizations may affect the production system. A UAT environment should be used to test all configuration or migration scripts and procedures, before they are applied to the production environment. This should ensure that all upgrades to the production environment will be completed reliably without errors. |
Service Level Agreement
This Quark Service Level Agreement (this “SLA”) is a policy governing the use of the Included Services (listed below) and applies separately to each account using the Included Services.
The following are the standard Service Level Agreements (SLA’s) in use for providing the Included Services (listed below) by Quark, when purchased with Production licenses. These will be in use, unless individual additional terms have been agreed to in a separate contractual document, approved and signed by the Quark Management Team.
Included Services
- Quark Publishing Platform Hosting
- Quark Publishing Platform NextGen SaaS Service
- Quark Docurated SaaS Service
Cloud Hosting Service Levels
1. Access. Quark shall make the Production hosting service available twenty-four (24) hours per day, seven (7) days a week with the minimum uptime level shown below, for production environments. These numbers are based on uptime levels Quark receives as part of its IaaS, from its Cloud Service Providers (dependent on the environment purchased and component types used).
Such service availability numbers do not, however, include regularly scheduled maintenance or any unscheduled downtime due to failures beyond Quark’s control (such as errors or malfunctions due to Customer’s computer systems, local networks, or Internet connectivity).
Quark makes two SLA commitments for the Included Production Hosting Services:
- For all environments that are running a single Instance, in one Availability Zone, we will ensure availability 99.5% of the time, in any given month (This is the base level commitment provided with all included services).
- For all environments that have two or more instances deployed across multiple Availability Zones, we will ensure at least one environment is available 99.75% of the time, in any given month (Available to purchase as an additional service called Active Redundancy).
Please consult with your Quark support or cloud team representative, if any information is needed as to which category your environment falls into.
1.1. Minor Hosting Environments are not subject to this SLA. Minor Environments are sold at a lower price point and as such are not generally deployed with the same infrastructure resources as a Production level environment. These environments are much more flexible in their usage, for testing and updating of applications and therefore cannot be guaranteed at the same availability level as the production level SLA. Specific SLA requirements for these environments can be provided if needed and will incur additional cost.
Minor environments are representative for validation and testing purposes, but not replicas of Production, meaning performance levels should not be expected to be the same as Production environments.
2. Scheduled Maintenance and Upgrades. A regular scheduled maintenance window will need to be agreed. Quark shall conduct scheduled service maintenance outside of Core Business Hours or on weekends, where this is possible. If this is not possible, Quark support staff will work with the customer admin to minimize disruption. Quark shall give the Customer at least seventy-two (72) hours prior notice of the exact date and time of such scheduled maintenance via e-mail or other timely means of communication.
2.1. Demo/Sandbox level environments are provided with no SLA and will be maintained and upgraded at Quark’s discretion.
2.2. Product version upgrades can be requested by a customer admin contact, only after 30 days have elapsed, following the release date for a new version of a Quark application. The Hosting contract entitles the customer to one major version upgrade per year within the hosting service price, with other upgrades being able to be purchased via professional services. Downtime will need to be scheduled with the customer admin contact for upgrade requests. Downtime will be minimized, as upgrade employees will be trained and practiced in the upgrade of the software and if scheduled can be outside of peak environment usage times.
2.3. Customers that choose to stay on older versions of the application cannot be guaranteed that all fixes built will be backwards compatible with their version. Supported versions fr fixes are current and current-1.
3. Data Retention and Recovery. Quark shall backup the Production Hosting service and other environment levels as follows:
| Environment Level | Backup Cycle | RPO | RTO |
|---|---|---|---|
| Production | Daily | 4 hours (point in time recovery) | 8 hours for in region issue and recovery in separate AZ 24 hours if primary region is down – cross region recovery |
| UAT/Staging | Daily | 24 hours | 24 hours |
| QA/Test | Daily | 24 hours | N/A |
| Development | Daily | 24 hours | N/A |
3.1. Backups are kept for 30 days, offering a maximum restore point of 30 days. Backups will be stored in encrypted form, either in a secure secondary data center location or using a Cloud Service Provider service, that offers redundancy as standard. Quark shall implement sufficient measures to ensure that the backup data is accessible and maintained in a manner to enable restoration of the backup version of the service in the event of a system malfunction or outage.
3.2. Recovered environments will ensure basic product functionality and will be at 25-50% capacity of primary environments. Other recovery timeframes or requirements can be discussed but will incur additional cost. A disaster recovery test will be performed annually, to ensure the processes used, resources needed, and data format are correct, to allow this timeframe to be achieved.
3.4. Quark will restore the service to a mutually agreed backup point, as part of normal service delivery, if an issue in data integrity is seen, as the result of issues with the service being delivered i.e. issues with maintenance activities, the infrastructure, services or the application itself.
Quark does not guarantee to restore the data to a backup point, due to a customer end user having corrupted data or having incorrectly removed data from the system, whilst using the application or its API’s. The customer should reach out to the Quark service desk and an assessment will be made on what can be done. This will usually incur additional cost.
3.5. All data will be kept in the system for the duration of the service subscription, unless removed by the customer beforehand. Up to 30 days after the end of a subscription the data will be securely stored and the customer can request for it to be temporarily restored and made available, to aid only in data export activities. After the 30-day retention, the data will be permanently removed from the system, but may remain in standard backup cycles for a total of 60 days post end of subscription.
3.6. If a customer reinstates their subscription outside of the 30-day retention period, there will be no guarantee that their previous customer data will be available and the customer may be treated as a net new customer from a data perspective.
4. Requests for Support. Quark service representatives will be available to respond to support requests via email, online ticketing portal and phone. Quark support representatives shall respond to all customer support requests in a timely and professional manner and in accordance with our Product Support SLAs.
5. Security Measures. Quark shall take, at a minimum, the following measures to protect the Service:
- Single tenancy, with dedicated Virtual Private Cloud
- Encryption in transit (TLS 1.2 and security certificates)
- Encryption at rest – Volume encryption as standard
- Firewall and security groups
- Resource monitoring and resource threshold alerting
- IP whitelisting available at customer request
- Role-based access control
- Full segregation of hosting environments from any standard Quark internal network, ensuring segregation of duties and no service data transfer.
- Penetration testing (performed annually as part of the service)
SaaS Service Levels
1. Access. Quark shall make the Production application service available twenty-four (24) hours per day, seven (7) days a week with the minimum uptime level of ninety-nine and eight tenths of a percent (99.8%) measured on a monthly basis. This is based on uptime levels Quark receives as part of its IaaS, from its Cloud Service Provider and the inclusion of components in the system being deployed over multiple Availability Zones.
Such service availability does not, however, include regularly scheduled maintenance or any unscheduled downtime due to failures be
yond Quark’s control (such as errors or malfunctions due to Customer’s computer systems, local networks or Internet connectivity).
1.1. Minor SaaS Environments are not subject to this SLA. Minor Environments are sold at a lower price point and as such are not generally deployed with the same infrastructure resources as a Production level environment. These environments are much more flexible in their usage, for testing and updating of applications and therefore cannot be guaranteed at the same availability level as the production level SLA. Specific SLA requirements for these environments can be provided if needed and will incur additional cost.
Minor environments are representative for validation and testing purposes, but not replicas of Production, meaning performance levels should not be expected to be the same as Production environments.
2. Scheduled Maintenance and Upgrades. Quark shall conduct scheduled service maintenance outside of Core Business Hours or on weekends, where possible. If this is not possible, Quark support staff will work with the customer admin to minimize disruption. Quark shall give the Customer at least seventy-two (72) hours prior notice of the exact date and time of such scheduled maintenance via e-mail or other timely means of communication.
2.1. Demo/Sandbox level environments are provided with no SLA and will be maintained and upgraded at Quark’s discretion.
2.2. Upgrades to Production and Minor levels of QPP NextGen application environments will be agreed with the customer admin, before any activity would occur. Upgrade of the application will incur downtime.
2.3. Planned upgrades to the Production Docurated multi-tenant systems will be delivered as per the product release schedule and communicated to the customer admin contact well in advance. Customers must receive the product updates at the same time as the other multi-tenant customers, unless they have purchased a single-tenant environment.
Planned upgrades to the Docurated UAT multi-tenant systems will be delivered as per the product release schedule and communicated to the customer admin contact well in advance. As they live on a different cluster to Production environments, upgrades will be scheduled ahead of any new versions being delivered to Production, to allow customer testing. Customers must receive the product updates at the same time as the other multi-tenant customers, unless they have purchased a single-tenant environment.
2.4. Customers that choose to stay on older versions of the applications cannot be guaranteed that all fixes built will be backwards compatible with their version. Supported versions for fixes are current and current-1.
3. Data Retention and Recovery. Quark shall backup the service as follows:
| Environment Level | Backup Cycle | RPO | RTO |
|---|---|---|---|
| Production | Continuous | 4 hours (point in time recovery) | 8 hours for in region issue and recovery 24 hours if primary region is down – cross region recovery |
| UAT/Staging | Daily | 24 hours | 24 hours |
| QA/Test (QPP NG Only) | Daily | 24 hours | N/A |
| Development (QPP NG Only) | Daily | 24 hours | N/A |
3.1. Backups are kept for 30 days, offering a maximum restore point of 30 days. Backups will be stored in encrypted form, either in a secure secondary data center location or using a Cloud Service Provider service, that offers redundancy as standard. Quark shall implement sufficient measures to ensure that the backup data is accessible and maintained in a manner to enable restoration of the backup version of the service in the event of a system malfunction or outage.
3.3. Recovered environments will ensure basic product functionality and will be at 25-50% capacity of production environments. Other recovery timeframes can be discussed but will incur additional cost. A disaster recovery test will be performed annually, to ensure the processes used, resources needed, and data format are correct, to allow this timeframe to be achieved.
3.3. Quark will restore the service to a mutually agreed backup point, as part of normal service delivery, if an issue in data integrity is seen, as the result of issues with the service being delivered i.e. issues with maintenance activities, the infrastructure, services or the application itself.
Quark does not guarantee to restore the data to a backup point, due to a customer end user having corrupted data or having incorrectly removed data from the system, whilst using the application or its API’s. The customer should reach out to the Quark service desk and an assessment will be made on what can be done. This may incur additional cost.
3.4. All data will be kept in the system for the duration of the service subscription, unless removed by the customer beforehand. Up to 30 days after the end of a subscription the data will be securely stored and the customer can request for it to be temporarily restored and made available, to aid only in data export activities. After the 30-day retention, the data will be permanently removed from the system, but may remain in standard backup cycles for a total of 60 days post end of subscription.
3.5. If a customer reinstates their subscription outside of the 30-day retention period, there will be no guarantee that their previous customer data will be available and the customer may be treated as a net new customer from a data perspective.
4. Requests for Support. Quark service representatives will be available to respond to support requests via email, online ticketing portal and phone. Quark support representatives shall respond to all customer support requests in a timely and professional manner and in accordance with our Product Support SLAs.
5. Security Measures. Quark shall take, at a minimum, the following measures to protect the Service:
- Multi tenancy offering with shared VPC and also Single tenancy offering, with dedicated VPC (Additional cost)
- Encryption in transit (TLS 1.2 and security certificates)
- Encryption at rest – Volume encryption as standard
- Firewall and security groups
- Resource monitoring and resource threshold alerting
- IP whitelisting available at customer request (Single tenant only)
- Role-based access control
- Multi-factor authentication can be applied and controlled by integration with customer’s IDP (SAML2)
- Full segregation of SaaS environments from any standard Quark internal network, ensuring segregation of duties and no service data transfer.
- Penetration testing (performed annually as part of the service)
Version 1.0
Effective November 20, 2021