Last modified at: December 15 2024
Below are links to the Terms of Service and Service Level Agreements (SLA) for our third-party service providers.
The SLA's for Ardoq and Appfarm are provided below this section.
The Service are provided "as is" as standardized service; the right to use is not conditional or tied to a specific version or functionality at a certain time, but allows access to and use of the Service as is at all times.
Ardoq reserves the right to make improvements, add, modify or remove functionality, or correct any errors or defects in the Service at its sole discretion, without any obligation or liability resulting from such act or defects. Ardoq will however not remove functionality which in Ardoq’s reasonable opinion must be considered as core functionalities for a service such as the Service.
Ardoq and the Customer agree that the Service will not always be completely free of errors and that the improvement of the Service is a continuous process. The Customer is also aware that successful use of the Service is dependent on equipment and factors (such as sufficient internet connection) that the Customer has the responsibility for. Ardoq is not liable for the discontinuance or disruption of the operation of the Service caused by the Internet or any third party service the Customer needs in order to access the Service, including operating systems etc.
Ardoq is available on the following browsers:
And have the following system requirements for best performance:
Third party software and operating system updates etc. may influence the usability of the Service, and Ardoq has no responsibility in this regard. Ardoq will however always use best efforts to accommodate and develop the Service for updates etc. on supported operating systems.
Ardoq is only responsible for the functioning of the Service as such, and undertakes the following obligations regarding error handling with regards to the Service:
The repair time stated in the table above starts when the Customer has given Ardoq notice of the error and sufficient information to assess and understand what the error comprises. Notice shall be given by written e-mail to support@ardoq.com or via Ardoq’s online chat channel, available both within the Service and on https://www.ardoq.com.
If Ardoq has not succeeded in curing a category A or B error within the repair time stated, the Customer is entitled to a period of free extension of the service, and must claim such free extensions within 90 days after the error notification was sent to Ardoq. The free extension for failing to meet the repair time for category A errors shall be 14 days. For category B errors the free extension shall be 4 days. For category C errors no free extension is given. Total free extension periods per year is limited to 28 days. The above described free extensions shall be the only claim the Customer may be entitled to in case of failure to meet the repair times stated above.
A category A error lasting more than 10 days is considered a material breach. The same applies for a category B error lasting more than 20 days.
Planned downtime is not considered an error. Downtime may be necessary to perform updates or maintenance in hardware or software from time to time. Ardoq may have planned downtime up to 10 times each calendar year. Planned downtime shall always be notified at least five (5) business days in advance and shall be done outside of normal business hours (0900-1700 CET) if possible. For planned downtime of up to 24 hours, notification shall be given at least ten (10) days’ in advance. Planned downtime according to this clause is not considered as a breach of contract.
Ardoq may use sub-contractors to provide the Service including all support and maintenance. To the extent a subcontractor processes personal data for which the Customer is data controller, the Data Processing Agreement sets out requirements in this regard.
Ardoq shall provide backup of the Customer’s data, to restore it after a data loss event.
For support purposes, Ardoq has internal administrators who can access Customers’ data. Ardoq will never access Customers’ data without prior approval from the Customer. Logs are kept of any access by Ardoq administrators.
The terms set out herein apply to all use of Appfarm products and services unless otherwise explicitly set out in the Appfarm Subscription Form, the Software Service Agreement or otherwise agreed in writing between the Parties.
Appfarm Customers depend on stability and integrity with respect to access to our services and service stability is a key priority for Appfarm in all operations.
This Service Level Agreement describes which expectation our Customers can have with respect to service availability and error correction in the event of disruption of service and other support requests. The services under this Service Level Agreement will be available only for the appointed administrator users of the Customer who in turn will be responsible for managing service requests and inquiries from internal and external parties.
1 OVERALL RESPONSIBILITIES TO MAINTAIN AVAILABILITY AND PERFORMANCE OF THE SERVICES
Appfarm undertakes to establish and maintain a service organisation available to assist the Customer in a timely and professional manner in the event of software malfunction or other errors to the Service and/or additional service requests made by the Customer.
Even though Appfarm cannot guarantee that the Service as defined in the Software Service Agreement will be performed error-free or uninterrupted, or that Appfarm will be able to remedy errors or defects that occur in the Service, Appfarm will use all reasonable efforts to ensure that all Customers have continued and reliable access to the Service. Consequently, Appfarm will respond to the Customer service inquiries in accordance with the service levels and routines as described in this Service Level Agreement.
2 SERVICE AVAILABILITY
Appfarm is responsible for hosting, maintenance and supervision of the Service, including technical infrastructure and functional performance. In principle, the Service shall be available for the Customer all day all year other than in the event of planned maintenance or scheduled downtime.
Any planned downtime with effect on end user applications with an expected downtime of 15 minutes or more shall be communicated to the Customer a minimum of 3 working days in advance. Scheduled downtime shall be planned to time periods when expected use of the Software is at a minimum (e.g., nights).
In the case of any unexpected downtime, Appfarm shall promptly investigate the root cause of the issue, and as soon as possible inform the customers through https://status.appfarm.io/, including information about a plan of action and best estimate of time to completion. Appfarm shall keep the Customer regularly informed with current status of the issue until the Service is restored. However, Appfarm cannot be held liable for any costs or loss, direct or indirect, that the Customer might incur as a result of lack of availability of the Service.
3 WARRANTY INCIDENTS – SOFTWARE FLAWS AND ERRORS
Appfarm undertakes to initiate action to correct software malfunctions and errors covered by the Appfarm warranty as set out in the Software Service Agreement upon request of the Customer.
Upon receipt of notification from the Customer, Appfarm will initiate work based on the following priority schedule system:
Services are provided only within normal office hours (0800-1600 CET). Availability outside office hours are available upon request unless covered by the agreed SLA.
In the unlikely event that Appfarm does not meet its response times for P1 and P2 category incidents, the Customer will be entitled to a compensation, deductible against subsequent fees and costs, at a rate of NOK 400 per hour calculated in 30 minute increments, up until Appfarm has initiated its response in accordance with this SLA.
4 SLA EXCLUSIONS FOR SOFTWARE F LAWS OR ERROR
Appfarm is not responsible for any failure to meet any obligation under this Service Level Agreement relating to software flaws or errors for which Appfarm is responsible under the Software Service Agreement in the following situations:
a) Where the failure is caused by planned maintenance. Planned maintenance is maintenance of which notice has been given in advance to the Customer by Appfarm. Usually, Appfarm will endeavor to give at least 1 week’s notice in writing of planned maintenance, but this may not always be possible in cases of emergency or upstream vendor maintenance.
b) Where the failure is caused by the Customer, through either a failure to comply with the Customer obligations in this Service Level Agreement or the Software Service Agreement or a failure of equipment or utilities supplied or controlled by the Customer, or through a failure to follow the requisite change control and reporting obligations, hereunder where the failure is the result of modeling errors or similar circumstances controlled by the Customer.
c) Where the failure is caused or extended by a failure by the Customer to fully assist Appfarm in fault correction (for example by preventing or delaying access to Customer resources or where a designated Customer contact is unreachable using the agreed contact details).
d) Where the failure is attributable to errors, malfunctions, updates or similar changes in and to software systems to which applications in connection with the Service have been integrated.
e) Where the failure is caused by any other circumstances that are beyond Appfarm’s reasonable control.
5 REPORTING PROCEDURES
All inquiries concerning software flaws and errors under this SLA shall be reported to the Appfarm Service Desk via e-mail: support@appfarm.io, and will be assigned a unique service request identification for all further correspondence.
All inquiries shall include a clear and evident description of the situation and should thoroughly explain the behavior of the event and its consequences for the use of the Service as well as a description of the proposed assistance needed.
6 TERM AND TERMINATION
This Service Level Agreement shall remain in force for the full term of the Software Service Agreement under which the Customer is granted access to the Services and lapses upon the expiry of the Software Service Agreement.
7 GOVERNING LAW – LEGAL VENUE
This Agreement is governed by the substantive laws of Norway and any and all disputes related to the Agreement are subject to the exclusive jurisdiction of Oslo tingrett (municipal court).
vSept 2023
This Service Level Agreement (“SLA”) is agreed between BiZZdesign B.V., having its offices at Capitool 15, Enschede, The Netherlands, or one of its wholly owned subsidiaries (“BiZZdesign”), and the Customer (“Customer”).
Definitions
Authorized User: User authorized to submit Support Requests to BiZZdesign. An Authorized User is designated by the Customer in consultation with BiZZdesign. The number of Authorized Users is based on a fair use policy.
Beta Services: Product Functionality, made available to the Customer in beta. Beta Services are intended for evaluation purposes and not for production use. Beta Services might be removed without notice.
Improvement: Additional software that applies to a specific Release and resolves imperfections in a previous Version.
Cloud Services Providers: Third parties of which BiZZdesign uses Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) technology to support its SaaS Service.
Customer: The party that has a supply agreement with BiZZdesign concerning the delivery of a Software Product and/or Service.
Customer Data: All electronic data or information submitted by Customer to the Software Product.
End of Life Procedure: Procedure for evolving Functionality in the Software Product.
Emergency Maintenance: Maintenance required to ensure availability of the SaaS Service, to prevent severe SaaS Service degradation, or to protect the integrity and confidentiality of the Customer’s Data. The urgent nature of execution prevents BiZZdesign from notifiying customers using the normal notification procedure.
Functionality: The usage functions and usage possibilities of the Software Product provided by the Software Product Version according to the Software Product Documentation.
Maintenance: Preventative, corrective or adaptive maintenance to a Software Product.
Maintenance Window: Period during which Planned and Emergency Maintenance may be performed.
Master Agreement: Agreement between BiZZdesign and the Customer, concerning the Software Product and/or the Services.
Office Hours: 8:00 -18:00 in the local time zone of the Customer’s main office location.
Planned Maintenance: Maintenance performed by BiZZdesign on the Software Product outside Office Hours of which Customer will receive a prior notification when the maintenance is expected to cause material interruptions to the of the SaaS Service.
Release: Release of a Software Product.
SaaS (Software-as-a-Service) Service: A Software Product managed by or on behalf of BiZZdesign with its Functionality made available to the Customer via the internet.
Services: The services ordered by the Customer.
Service Availability: The availability percentage of a full calendar month of the SaaS Service to the Customer after deduction of Unplanned Outage.
Support Portal: Portal used by the Customer for any Support Requests made by Authorized Users.
Service Level: Level of (an aspect of) a Service provided by BiZZdesign.
Support Request: A ticket raised by an Authorized User in the Support Portal, covering a Software Product Defect, a question or a suggested improvement.
Software Product: BiZZdesign software delivered as SaaS Service or made available for on premise deployment by the Customer.
Software Product Defect: The Software Product produces an incorrect response, error message or failure to respond according to the Software Product Documentation for the Version being used.
Software Product Documentation: Collection of manual(s), installation and configuration guide(s) describing the Software Product and its Functionality, made available by BiZZdesign for the latest Version of the Software Product.
Support Services: Support provided by BiZZdesign to the Customer as part of the Master Agreement.
Unplanned Outage: Unavailability of the SaaS Service due to an outage, excluding Planned and Emergency Maintenance outside Office Hours, and including Emergency Maintenance during Office Hours.
User: Natural person within the Customer’s organization who uses the Software Product.
Version: General indication for a relevant Version of the Software Product. A Version consists of a combination of main version number and a unique identifier. For example: Version ‘4 (2019-04-30)’.
1.1. Scope.
This SLA describes the Maintenance and Support Services offered by BiZZdesign, and the Service Levels for the Maintenance, Support and SaaS Services within the context of the Master Agreement between BiZZdesign and the Customer. This SLA defines the Level of these Services and the allocation of responsibilities. BiZZdesign makes no warranties with respect to the content of this document. This document may not be reproduced in whole or in part by whatever means electronic or physical without prior written consent from BiZZdesign.
Any Beta Services are not part of the scope of this SLA.
This SLA applies if Maintenance and Support Services have been contracted between BiZZdesign and the Customer.
1.2. Proprietary rights.
BiZZdesign reserves all rights, title and interest in and to Software Products and the
Service, and all modifications and improvements thereto, created by BiZZdesign, including all related intellectual property rights.
2.1. Maintenance and Support Services
BiZZdesign Maintenance and Support Services include:
▪ Access to the Support Portal for Authorized Users;
▪ Submission of Support Requests by Authorized Users via the Support Portal;
▪ Availability of new Software Product Releases;
▪ Software Product Documentation available to all Users;
▪ Handling of Support Requests according to the classifications defined in section
2.5.
The following Support Requests are not part of BiZZdesign Maintenance and Support
Services and may be referred to BiZZdesign consulting or training:
▪ Functional “how to” questions;
▪ Help on custom reports, views, scripts produced by the Customer;
▪ On-site Support Services.
Priority class 1 Support Requests (see paragraph 2.5 for classifications) can be
submitted 24x7 via the Support Portal or via phone using: +1-205-619-9161. Australian Customers can use the phone number +61 –18 -00954779.
Contacting this phone number for other purposes than submitting Support Requests classified as Priority class 1 may lead to related costs being charged to the Customer.
2.2. Supported Software Product Versions
BiZZdesign provides Support Services for the latest Software Product Version and all Software Product Versions released up to 12 months prior to the current date.
Software Product Defects will generally be resolved with a new Software Product
Version; where a Software Product Defect has already been resolved in a newer
Software Product Version we will not provide resolutions in older Software Product
Versions.
The BiZZdesign Support Services include access to Software Product Documentation for the latest Software Product Version.
2.3. End of Life Procedure
BiZZdesign continuously evolves the Software Products. This may result in
Functionality being made end of life, typically because new Functionality replaces
previous Functionality. BiZZdesign will announce the end of life of Functionality
through the Support Portal and will make commercially reasonable efforts do so at least 12 months before removing the previous Functionality from the Software
Product.
2.4. Raising Support Requests
Support Requests can be submitted through our Support Portal by Authorized Users. Up-to-date instructions for submitting Support Requests, including a link to the Support Portal can be found at https://support.bizzdesign.com/.
When a Support Request is raised, the Authorized User will receive a confirmation per email with a request identifier. This email received is purely informational and cannot be replied to. All communication takes place through the Support Portal. Notification emails contain a link to the request, so that it can be easily accessed.
2.5. Request priority classes
When a Support Request is submitted via the Support Portal, priority will be assigned based on information provided by the Authorized User and the class definitions below.
▪ Priority class 1
o The Software Product cannot be used by any User due to a Software Product
Defect or Unplanned Outage causing critical business impact. No viable
workaround exists for the issue.
o For priority class 1 Support Requests the target response time is 1 hour, 24x7,
with a targeted resolution time of no more than one working day.
▪ Priority class 2
o Serious degradation of the Software Product due to a Software Product
Defect causing major business impact and affecting a substantial number of
Users. No viable workaround exists for the issue.
o For priority class 2 Support Requests the target response time is 2 hours
within the applicable Office Hours and the target resolution time is two
working days.
▪ Priority class 3
o Software Product problem affecting Users due to a Software Product Defect
causing moderate business impact. No viable workaround exists for the issue.
o For priority class 3 Support Requests the target response time is 1 business
day within the applicable Office Hours and the resolution will be provided in a
subsequent Software Product Version Release.
▪ Priority class 4
o Any Support Request which does not qualify for the other priority classes.
BIZZDESIGN SLA - vSept2023 Page 5 of 9.
o For priority class 4 Support Requests the target response time is 2 business
days within the applicable Office Hours and the target resolution time is at the
discretion of BiZZdesign.
Target resolution times are dependent on the Customer providing all requested
information. Any time elapsed between a request for information being submitted to the Customer and the requested information being provided will not count towards the target resolution time.
Based on available information , BiZZdesign may update the priority class during the handling of the Support Request (f.i. priority may be lowered when a work around becomes available). The response and resolution times for the updated priority will be leading. At the request of the Customer, BiZZdesign will provide an explanation on the update of priority.
Resolution of a Software Product Defect may require a new Software Product
Version. In these circumstances, BiZZdesign will aim to provide a temporary
workaround until the Software Product Defect is resolved.
Support Requests for Ad-Ins will always receive priority class 3 or 4.
2.6. Resolution and closure policy
When a resolution is provided for a Support Request the request marked as resolved and the resolution is communicated to the Authorized User associated with the Support Request. The resolution may be one of the following (but is not limited to this list):
▪ Instructions to resolve the request;
▪ Instructions for a workaround for the request;
▪ New Software Product Version which resolves the request;
▪ Confirmation that the Software Product is functioning according to the Software
Product Documentation;
▪ Updates to the Software Product Documentation;
▪ The Customer indicates the ticket can be assigned the “Resolved” status or has
not responded within the periods listed below;
▪ For issues with priority class 3 or 4: the Customer has been provided with an
request identifier to track the request in the release notes for future Software
Product Versions.
Once a Support Request is marked as resolved and the Authorized User associated with the Support Request does not respond within 3 working days, the Support Request will be closed. Furthermore any Support Request in which the associated Authorized User does not respond to BiZZdesign communication requests within 10 working days will also be marked as resolved.
Once a Support Request is closed, it cannot be re-opened.
2.7. General conditions
BiZZdesign can only provide Support Services to the Customer if the Customer
complies with the following general conditions:
▪ The Customer must process Support Requests in the way as described in this
SLA.
▪ The Customer must designate Authorized Users in consultation with BiZZdesign.
These Authorized Users will be responsible for offering first-line Support Services
within the Customer’s organization and can raise Support Requests to BiZZdesign. The Customer must ensure that Authorized Users have reasonably sufficient knowledge of, and experience with, the Software Products and Services of BiZZdesign.
▪ One or more Authorized Users must be available for consultation during the
handling of Support Requests.
▪ The Customer must strictly comply with all agreements, instructions, rules and the applicable legislation and regulations.
3.1. Deployment
The SaaS Service is managed and operated by BiZZdesign.
3.2. Availability
a) Service Availability
o BiZZdesign commits to use commercially reasonable efforts to provide a Service Availability of 99.6%.
b) Maintenance
o BiZZdesign will execute Planned Maintenance in Maintenance Windows, during which the SaaS Service is not available for usage.
o Planned Maintenance will always be scheduled in Maintenance Windows outside of Office Hours and will be announced to the Customer at least 4 business days before Maintenance execution. Some of the Planned Maintenance is planned in recurring Maintenance Windows. When performing Emergency Maintenance BiZZdesign will exercise reasonable efforts to inform Customer in advance before any interruptions of the SaaS Service, but such prior notice is not guaranteed.
3.3. Customer Data
a) Data ownership. All Customer Data entered by the Customer using the SaaS
Service is, and remains, owned by the Customer. All related hardware is owned
or operated by BiZZdesign or Cloud Services Providers.
c) Storage locations. BiZZdesign uses various locations across the globe, including
locations within Europe, North America and APAC, to store Customer Data.
d) Backups. A backup of the Customer Data is created every 24 hours to multiple
physically separated locations.
e) Exit plan. Until termination of the hosting service the Customer is able to extract
the data and/or files in open formats like ArchiMate Exchange and/or BPMN.
Following the termination of the hosting service the Customer Data uploaded to
or stored within the SaaS Service by the Customer will be removed or otherwise
rendered inaccessible within 90 days unless BiZZdesign is required by law to store
the Customer Data for a longer period.
3.4. Usage of SaaS Service
a) General conditions for usage of BiZZdesign SaaS Service
o The Customer must use the SaaS Service only for the agreed purpose
o The Customer must strictly comply with all requirements, agreements, applicable rules, legislation and regulations and instructions, including operating instructions, system requirements and Software Product Documentation.
b) Usage restrictions. Customer will not make any SaaS Service or content available to anyone other than the Users, unless expressly stated otherwise in the Main Supply Agreement. The Customer will not use the SaaS Service to store or
transmit infringing, libelous, or otherwise unlawful, tortious or malicious material,
or to store or transmit material in violation of third-party rights. BiZZdesign
bears no responsibility in case of corruption of Customer Data if Customer uses
the SaaS Service contrary to any usage restriction.
c) Fair use policy. The Customer will not use the SaaS Service in ways that cause or can reasonably be expected to cause high demands on the SaaS Service, such as performing automated requests to the SaaS Service at a high frequency (“abuse”). BiZZdesign reserves the right to temporarily suspend the SaaS Service
to (a) User(s) or (an) IP Addres(es) when BiZZdesign detects abuse of the SaaS Service.
d) Vulnerability testing. The Customer is not allowed to probe, scan, test or
otherwise attempt to asses the SaaS Service for vulnerabilities, or to otherwise
attempt to breach security or authentication measures, without prior written
consent from BiZZdesign through the Support Portal.
3.5. Security and monitoring
a) Protection and prevention. BiZZdesign will take organizational, physical, and
technical precautions to protect the security of Customer Data, including
encryption, access control, monitoring and security protocols. Those precautions
will include measures to prevent unauthorized access, use, modification or
disclosure of Customer Data.
b) Disaster recovery. BiZZdesign will maintain a disaster recovery plan for the SaaS
Service. Recovery Time Objective (RTO) is 3 days (time during which the SaaS
Service is unavailable), Recovery Point Objective (RPO) is 24 hours (work lost).
c) Monitoring. BiZZdesign may monitor usage of Functionality to improve its
Software Products and Services.
d) Notification of security issues found by Customers. If the Customer is, or becomes aware of security vulnerabilities or other deficiencies in the SaaS Service that might lead to loss, unauthorized alterations or unauthorized access to Customer Data stored in the SaaS Service by either the Customer or other BiZZdesign customers, the Customer must report such issues to BiZZdesign immediately. The correct channels for reporting security issues are published at the BiZZdesign Support Portal (https://support.bizzdesign.com/).
