General & Service Terms & Conditions
Download the General & Service Conditions in PDF here:
General conditions
Table of contents
1. Introduction
2. Validity Terms and Conditions
3. Modification of Terms and Conditions
4. Duration of AI-as-a-Service.
5. License and additional services
6. Delivery Terms
7. Maintenance and failure
8. Warranty Limitation
9. Rate base
10. Billing
11. Adjustment agreement
12. Termination of Agreement
13. Liability
14. Intellectual property rights
15. Privacy & confidentiality
16. Legal Affairs
1. Introduction
We would like to inform you about what you can expect from us when using our AI-as-a-Service. These terms and conditions are written in understandable language to ensure transparency. If there are ambiguities, we are open to your questions.
2. Validity Terms and Conditions
These Terms are part of our agreement and apply during the term, including any renewals.
3. Modification of Terms and Conditions
The most recent version of the Terms and Conditions is always applicable. Changes are communicated in a timely manner and customers have the option of not accepting them, with two months' notice under the old terms.
4. Duration of AI-as-a-Service.
The agreement is for an indefinite period, unless otherwise agreed. The notice period for customers is two months before the new annual period, while we have a notice period of six months for proportionality. With our AI-as-a-Service, you receive a license to use our software and the right to additional services. For this license and services, we charge the agreed rate and you will receive an invoice each month.
5. License and additional services
The AI-as-a-Service includes the product components you purchase based on the rate base (numbers of policies). In addition, you pay a fixed amount per month for Hosting & Computing power. The components can be found on your invoice. You may only use the license for your own organization or its subsidiaries. In addition to the license to use our software, the AI-as-a-Service also entitles you to the following additional services:
- troubleshooting and support during the first three months, as long as it does not exceed 100 support hours;
- continuous monitoring of the software and implementing new releases;
- at least once a year, a periodic report including discussion with the Client's MT;
- consultancy to the extent specifically stated.
If you need additional services, not mentioned here, we are happy to provide them. In that case, we will indicate to you what costs we will charge for it, if any.
6. Delivery Terms
We believe it is important to keep our commitments. But sometimes there are unforeseen circumstances or we depend on third parties. Therefore, all deadlines specified by us are intended to be indicative; the mere exceeding of a specified deadline does not put us in default. In all cases in which exceeding a deadline is imminent or a deadline is not met, we will consult with each other as soon as possible and set a reasonable deadline to still fulfill all obligations properly.
7. Maintenance and malfunction
We may take all or part of the implementation of the AI-as-a-Service out of service for maintenance. We will not take our service out of service for longer than necessary and will do so outside of business hours if possible. Failures we will of course resolve as quickly as possible. For response times, please refer to the Service Levels in our Terms of Service.
8.Warranty limitation
AI predictions are based on statistical models and are provided on a best-effort basis. Onesurance assumes no liability for predictions not coming true or for decisions made by the Client based on these predictions.
9. Rate base
For the license fee, we work on the basis of the number of policies in your portfolio, for which we make a forecast. There is a fixed amount per policy per year for each product component. The rate base is the number of policies rounded down to ten thousand. Once a year, the rate base is redetermined and we increase or decrease the rate based on the numbers. We index rates annually, taking into account the Consumer Price Index (CPI) figure for the previous year, the annual change from July of the current year. The indexation takes effect from the first invoice in the following calendar year. We will inform you of the indexation each time.
10.Billing
Rates are indexed annually in accordance with the CBS CPI figure (year-on-year July). When expanding the number of policies, Onesurance may adjust the rate proportionally. We invoice the license per month in advance. You will receive all our invoices by email in pdf format. The payment period is thirty days.
11. Adjustment agreement
Adding product parts can be done at any time. Removing product items can only be done one year after full billing or at the end of the initial period if agreed upon. Please note that you must make a change and/or termination request one month prior to the new billing period and you cannot increase and decrease within the same quarter.
12.Termination of Agreement.
You can always cancel the license one year after full billing. Please note that you must notify us in writing or by email two months before the expiration of the new annual period. You can terminate the license mid-term within ten business days after the expiration of the initial three-month period. Upon termination, you will no longer have access to the software and associated data. Your data will be deleted within fourteen days. Our notice period is twelve months. We can terminate the agreement immediately if you fail to meet agreements and we have given you notice of default, pay invoices structurally late, or have not paid a non-dispute invoice after 60 days. We also have this right if you have filed for suspension of payment or bankruptcy. After termination of the agreement, data will remain available for export by the Client for 30 days, unless otherwise agreed in writing.
13. Liability
We make every effort to ensure that our software meets the specifications we specify. If errors do occur, we fix them as quickly as possible. We want our software to work optimally, and our service must also be good. Still, things can go wrong. If you have a claim as a result, we will work together to find an appropriate solution. If you have a complaint or claim, it is important that you report it to us as soon as possible. We can then work immediately to find a solution. Moreover, we must also report a claim to our carrier. Whatever goes wrong, we always want to find the right solution by mutual agreement. Our total liability due to an attributable failure in the performance of the agreement or on any legal ground whatsoever is limited to compensation of direct claim up to the amount of the price stipulated for that agreement (excluding VAT). If the agreement is primarily a continuing performance agreement with a term of more than one year, the price stipulated for that agreement shall be set at the total of the fees (excluding VAT) stipulated for one year. In both situations our maximum cumulative liability is limited to EUR 50,000. We can only be held liable for compensation of direct claim and not for any form of consequential damage. Consequential damages include in any case lost sales, lost profits, loss of data and missed opportunities. Neither of us shall be liable to each other in the event of force majeure within the meaning of the law. This also applies to force majeure of suppliers, power grid failures and failures that impede data traffic if the cause is not attributable to the parties themselves. In the event of intent or deliberate recklessness on the part of our company and/or our executive employees, we cannot invoke the limitations of liability.
14. Intellectual property rights
The intellectual property rights to the software are and remain with us. If a third party claims otherwise, we will indemnify you. The condition is that you inform us as soon as possible, cooperate in the investigation and let us handle the case. If the court finds that the intellectual property does indeed belong to a third party, we will ensure that you can continue to use the software or we will offer equivalent software. You are granted a non-exclusive, non-transferable, non-pledgeable and non-sublicensable right to use our software including use of our algorithms during the term of the agreement. It is not permitted to reproduce, disclose, reverse engineer, decompile or make available and/or make available to third parties for inspection, in whole or in part, the software and/or algorithms and/or our documents and materials without prior written permission. The data provided by Client shall remain the property of Client. Client grants Onesurance a right of use for the duration of the agreement to process this data for the purpose of service provision, quality improvement and benchmarking, provided it is anonymized.
15. Privacy & confidentiality
We will comply with all applicable requirements of the General Data Protection Regulation. We warrant to each other that all information, which we reasonably understand to be confidential or competitively sensitive, that we receive from each other before and after entering into the agreement will remain confidential. We will take all reasonable steps to protect such information. We would like to be able to mention in advertising or marketing activities that you are one of our valued clients. In doing so, we will carefully remove from the information to be used or published any information relating to your results and/or the work you have performed that could trace back to you.
16. Legal Affairs
All disputes arising out of or in connection with our agreement shall be submitted exclusively to the judgment of the competent court in Breda, the Netherlands. Our agreement, as well as all disputes related to or arising from our agreement, shall be governed exclusively by Dutch law. The United Nations Convention on Contracts for the International Sale of Goods (Vienna Sales Convention) shall not apply. Notices which we give to each other under this agreement shall be in writing. Written means by mail and/or e-mail, if addressed to the e-mail addresses of the signatories of the agreement. Any oral promises and agreements have no effect unless confirmed in writing by both parties.
17. Partner Strategy and Training
Implementation partners can be certified through a training program. Paid onboarding and training modules available to increase efficiency and adoption.
Contact details Onesurance B.V.
Visiting address: Rithmeesterpark 50 A1, 4838 AZ Breda | Basisweg 32, 1043 AP Amsterdam
Email: onesurance
Website: onesurance
Chamber of Commerce: 87521997
IBAN: NL25 INGB 0398 4072 82
VAT:NL 8643.18.315.B01
Terms of service Onesurance
1. Introduction
The parties wish to qualitatively manage each other's expectations and obligations regarding the performance of the services as described in the Agreement. In any cooperation, success depends on correct and timely mutual cooperation. Among other things, it is important that the Parties communicate clearly on both sides, with (important) information being shared in a timely manner.
This SLA sets forth the arrangements for the performance of the Service.
Agreement
The parties have an Agreement to use Onesurance s AI-as-a-Service (hereinafter "Agreement"). This Service Level Agreement (hereinafter referred to as the "SLA") is a part of this Agreement.
Applicability
This SLA applies to the production environment of Onesurance s AI-as-a-Service and associated portals and links. In addition, if agreed, an acceptance environment is available, terms and conditions for this are listed separately.
Purpose SLA
The SLA establishes agreements on service quality parameters with the aim of monitoring and reporting on the quality and performance of the service of both the product and support. The SLA covers the Availability of the AI-as-a-Service, the Backup and ongoing Availability of data, as well as the continuity of services from Onesurance. This includes the Services of Support.
Changes to existing SLA
This SLA is a living document to be reviewed and updated periodically to continue to meet the needs of both Parties. All enhancements will be made unilaterally. If a modification may have a negative impact on the Client, Onesurance will do so by mutual agreement and only after Client's approval.
Definitions
Capitalized terms shall have the following meaning or the meaning as provided elsewhere in this document:
Acceptance:
Customer's final and written approval of (parts of) the Service(s).
Handling time:
The time measured and recorded by Supplier (including Response Time) between:
- The time of reporting the Incident to Supplier and Supplier's notification to Customer that the Incident has been remedied;
- The time at which this is demonstrably reported by Supplier;
- The time the Service is available again.
Backup: a copy of files, data held on a data carrier to restore this information in the event of a system crash, data loss or other calamity.
Availability: time period expressed as a percentage of the total time measured over a full calendar month in which a Service is available under the appropriate conditions.
Call: a message (by phone/e-mail) from a person in Client's organization or a notification from Onesurances monitoring system.
Data Breach: a breach of confidentiality and/or of the integrity and/or of the Availability of Personal Data where unauthorized persons have inadvertently or unauthorizedly gained access to (client) Personal Data This may result from a variety of causes, such as a cyber-attack, human error, technical failure, or technical error. A Data Breach may result in the unauthorized access to, disclosure of, alteration of, or loss of personal data.
Service(s) means all work to be performed by Supplier on behalf of Customer under this Agreement, including all Services, functions and responsibilities not specifically described in this Agreement, but necessary for the proper and/or lawful performance and delivery of the described Services, functions and responsibilities.
Downtime: the period during which the Service is unavailable or unresponsive at all.
Holidays: national Holidays determined by the government and the days on which Supplier has announced to be closed. These days shall not be counted as a Working Day.
Users: the persons employed by or working for the Client and/or using the Acceptance Assistant because they are clients/clients of the Client.
Scheduled Unavailability: the period(s) during which Acceptance Assistant is unavailable due to scheduled and pre-announced (maintenance) work.
Implementation: the whole of actions and measures necessary to put all parts of the Services and supplied software, separately and in mutual coherence, into use in the organization of the Client, in such a way that all Users of the Client can work with it in accordance with the agreed use. If agreed, the Implementation also includes the conversion, the realization of the links necessary for the agreed use and the execution of the acceptance procedure.
Incident: an interruption, deviation, disruption, reduced Availability or reduced speed of an agreed upon service, resource or product.
Office Hours: the period during which Supplier can be reached on the Business Days.
Complaint: (written) expression of dissatisfaction with Supplier's services.
Supplier: Onesurance.
Maintenance Window: time period during which maintenance can be performed on the managed components.
Non-Availability: the periods when Acceptance Assistant is not accessible to the authorized Users in accordance with the agreed functionality as agreed in the service description.
Standard: the percentage of successful incident settlements within the promised times that Acceptance Assistant must meet as a minimum.
Client: the client of Onesurance.
Agreement: the Agreement and attachments
Force Majeure: unforeseen and uncontrollable circumstances beyond a Party's control that may adversely affect performance of the Service. Examples include natural disasters, terrorist activities, power outages, strikes, or other events beyond the reasonable control of that Party.
Parties: Contractor and Supplier jointly referred to as "Parties" and separately referred to as "Party",
Partner: the customer of Supplier, who purchases the Services and/or application from Onesurance .
Priority: the degree of urgency of the Incident, as described in Chapter 5.
Problem: Failure to comply due to an initially unknown cause which may lead to one or more Incidents.
Response Time: the time between receiving a report and when it is acted upon (registration, first contact with Client and start of diagnosis).
Recovery Point Objective (RPO): the maximum period during which data loss is acceptable in the event of a disaster.
Recovery Time Objective (RTO): the maximum time between an Incident and functionality being available again
Request for Change (RFC): a request from Client to change, add or remove a functionality.
AI-as-a-Service: Onesurance s application made available to authorized Users via the Internet.
Security breach: an Incident in which unauthorized persons gain access to data, applications, networks or devices without permission. This can lead to Data Breaches, loss of confidential information or other negative consequences for individuals or organizations.
Support: Supplier's central point of contact for Customer's Users.
Service Level: the level of a partial aspect of the Service(s) to be delivered by the supplier, expressed by means of an indicator.
Service Window: the time frame within which the Service(s) is/are performed.
Fee(s): all Fees agreed upon for the Services.
Working Days: a day falling within Supplier's Office Hours.
Change: a change carried out on (parts of) a Service or infrastructure, with such an impact (potentially) that a careful assessment should precede its introduction.
2. General AI-as-a-Service
Supplier makes its AI-as-a-Service available via the Internet and provides technical maintenance and management of the Services provided. Supplier makes its products available from an EEA-based data center. In order to make use of this, Customer must take care of a:
- Stable Internet connection with speed of at least 5Mbps;
- Chrome browser, equipped with the latest updates;
- Resolution of at least 1600 x 900 combined with a scale of 100%.
The Service is an AI-as-a-Service application and therefore has the following benefits and conditions:
- Client does not have to purchase the software and hardware on which this software is installed, but pays for the use of the AI-as-a-Service;
- Client accesses the AI-as-a-Service via a secure Internet connection;
3. Technical management by Onesurance
Technical maintenance and management will be provided by Supplier. This includes Infrastructure management, Data management, Security management, Compliance & audits and Performance optimizations. Of course, Supplier also takes care of the delivery of new functionalities in the application.
Infrastructure: Managing the hardware infrastructure, such as hosting, servers, and storage, required to support the AI-as-a-Service application.
Data Management: Managing the data stored and processed by the AI-as-a-Service application. This includes implementing, managing and monitoring Backup and Recovery procedures, ensuring data integrity and meeting data protection compliance requirements.
Security Management: Implementing and maintaining security measures to protect the AI-as-a-Service application from threats such as hackers, malware and Data breaches. This includes monitoring security events, performing penetration tests and implementing access control mechanisms.
Service Support: Providing technical support to end users of the application. This includes taking Incidents, handling RFCs and possibly providing paid training.
Compliance and Audits: Compliance with legal and industry compliance requirements such as the AVG, and standards around information and cyber security. In addition, Supplier shall cooperate with annual audits and PEN testing to ensure that the application complies with applicable laws and regulations at all times.
Performance maintenance and optimizations: Managing the systems and identifying opportunities for improving the performance of the AI-as-a-Service application, such as optimizing code and data processing.
Delivery of new functionalities: If new functionalities are needed then Customer can indicate this to Supplier and it will be built by Supplier at an agreed upon cost.
Functional Management Supplier is responsible for the functional management of the Service. This includes Accepting and processing user questions, Maintaining the facility, Performing periodic checks on the operation of the facility, Delivering data and requirements to Customer and collecting user feedback.
Acceptance and processing of user queries: The questions asked by end users must be accepted and processed by the Supplier. If the Customer notices that something is a bug then this can be submitted to Support of Supplier and it will be resolved. New functionalities (RFC) can be submitted via the Customer Success Manager. Generic RFCs are implemented free of charge, for Partner specific requests a Fee is requested which is communicated in advance.
Maintain Setup: The proposal includes an initial setup of the application by Supplier.
Delivery of data and requirements: If Client wants to migrate data, have a new link or request new functionality, then Client is responsible for delivering this information. For links, Customer is responsible for preparing the requirements, collecting the necessary information and credentials, and fully testing and approving the link. Supplier is not responsible for any errors in a prepared and agreed setup.
Collecting User Feedback: Client is responsible for collecting user feedback. With this feedback, Client will improve the user experience by requesting an RFC from Onesurance.
Functional Chain Testing: It is the responsibility of the Client to conduct regular chain tests, testing the functional operation of the application and links. These chain tests serve to ensure the quality of the setup and the integrity of the data. The purpose of this is to ensure that the system functions optimally and meets the specified functional requirements. These requirements can only be checked by the Client itself, as well as the authenticity of the data.
4. Application performance.
To work well with AI-as-a-Service, a fast-working application is very important. Of course, speed depends on several factors, including a well-functioning (Wi-Fi) network. Under optimal conditions, we aim for the following performance, excluding scheduled maintenance and Force Majeure, on a best-effort basis:
Type | Measuring point | Measurement time | Standard performance | Standard |
Availability | Uptime percentage | Monthly | 95% accessibility | 90% |
Speed | Frontend load time | When loading a page | 3 sec | 90% |
Capacity | Number of simultaneous users | During peak load | Max 50 users | 90% |
Recovery time | Time to resolve critical failures | After a critical failure | 48 hours | 90% |
It is the responsibility of the Client to ensure that the environment is regularly cleaned and maintained so that unnecessary data is removed and the system performs optimally without delays due to overload or redundant information that would prevent the above times from being met.
5. Availability of production environment AI-as-a-Service
Supplier commits to an Availability of at least 95% for its AI-as-a-Service, less Planned Unavailability. The performance indicators issued relate to Supplier's service(s) in a production environment and do not apply to Services in an acceptance environment. Availability is calculated per calendar month according to the formula:
Uptime = { ( T - D ) / T } * 100% T: Service Window per month D: Total Unavailability (Downtime) Downtime in a Maintenance Window, is excluded from the calculation. |
Our principles around Availability are:
1. Work that has an impact on the Availability of the AI-as-a-Service will be performed outside Office Hours as much as possible, about this maintenance Supplier will inform Customer in writing at least 7 days in advance. In exceptional situations the Supplier may have to perform these activities within Office Hours, this will only be done in case of high priority and after consultation with Customer.
2. Non-Availability due to the reasons and causes below cannot be attributed to Supplier and is therefore outside the Availability:
a) Maintenance work agreed with Customer in writing during the Maintenance Window
(b) Incidents due to Force Majeure.
6. Availability of acceptance environment AI-as-a-Service
If desired by Customer, Supplier will provide the possibility of setting up an acceptance environment. This will be discussed during the project phase and if necessary set up by Supplier, who will also be responsible for maintaining the environment. Supplier commits to an Availability of the acceptance environment of at least 85% for its AI-as-a-Service, less the Planned Unavailability. The Acceptance Environment Availability is lower than the production environment because test scenarios are regularly rolled out for our Partners, allowing for extensive testing before items go to production. The performance indicators issued relate to Supplier service(s) in an acceptance environment and do not apply to Services in a production environment. Availability is calculated per calendar month according to the formula:
Uptime = { ( T - D ) / T } * 100% T: Service Window per month D: Total Unavailability (Downtime) Downtime in a Maintenance Window, is excluded from the calculation. |
The principles around Availability for the acceptance environment are:
1. The acceptance environment will be updated with the new functionalities after consultation and by arrangement.
2. If an update needs to be implemented earlier then this will be discussed and implemented by mutual agreement at a time when the impact to Client is minimal.
3. Important updates are carried out during the day after the Client has been informed of them in a timely manner and has been able to take measures, if necessary, as a result, the application may be temporarily unavailable.
7. Measuring Availability.
To proactively measure Availability, Supplier uses:
- Monitoring of servers to measure whether they are active;
- Monitoring the AI-as-a-Service for activity and environmental load;
- Number of successful login checks on the AI-as-a-Service;
Login control principles:
- Login control assumes one login attempt per minute within the Service Window;
- Login attempts during the Maintenance Window are ignored.
A printout of non-sensitive information such as Availability in percentage can be provided upon request.
8. Monitoring the environment
Like the infrastructure, our AI-as-a-Service solutions and associated portals are monitored 24x7. If disruptions occur in the underlying infrastructure or on the application, the Supplier receives an automated notification. Supplier attempts to resolve the disruption immediately. Service Window
Supplier guarantees within the Service Window an Availability according to the Standard below.
Description | Availability | Note |
Service Window | 8:30 - 17:30 Monday through Friday | Exclusive Maintenance Window |
Maintenance Window | Announced and planned | If necessary with advance notice |
Standard Availability | 95% | Per month within the Service Window |
The Maintenance Window allows Supplier to perform scheduled maintenance on predetermined time frames.
Description | Availability | Note |
Maintenance Window | Announced and planned | Potential impact on Availability or Performance* |
*Maintenance with impact on Availability will be announced in writing at least 7 Business Days in advance, unless there is a security incident and/or urgent Change. In the latter case, Supplier will contact Customer's contact person here as soon as possible. If it is foreseen that an urgent Change may cause a conflict with regular maintenance in the Maintenance Window, Supplier will first perform the urgent Change and if possible after that the regular maintenance. If it is not possible to perform the regular maintenance, another time will be scheduled for this regular maintenance. The priority is always to implement the urgent Change. In order to guarantee the service it is important to implement relevant updates in a timely manner. Supplier therefore implements the new security updates according to the deadline below.
Rating | Lead time | Explanation |
Not critical | < 3 maanden | A (security) Incident that occurs where there is no business impact |
Medium Priority | < 1 maand | A (security Incident that occurs where the business impact is minimal and there is no risk of data breach. |
High Priority | Per direct, < 72 uur | A (security) Incident that occurs where a business impact is possible. |
Critique | Per direct, < 48 uur | A (security) Incident that occurs where a business impact is significant. |
9. Responsibilities testing after maintenance
Supplier is responsible for the uptime of the application and technology. After maintenance, Supplier will therefore perform a check on the operation of the functionalities. If any Changes are made in the setup of the application, Customer will be notified in advance by email. It is the Supplier's responsibility to perform a functional test after an update to check whether functionality still works as initially intended. Links are not modified without mutual consent (if the operation of the link changes) and are therefore outside the scope for testing after maintenance. Updating the acceptance environment, testing and release to production is always done based on pre-communicated planning from Supplier.
Support services
Support Requests
Supplier provides support on its AI-as-a-Service. For this purpose, Support from Supplier is available to answer and handle service requests (Calls). Service Requests may only be notified by Customer's project support. Telephone accessibility for this support is during Office Hours.
Service Desk service | Days | Period |
Support: +31 6 132 70 144 | Mon to Fri* | 08:30-17:30 a.m. |
*excluding Holidays
Reports that are posted are picked up within Office Hours based on Priority. The Priority is initially specified by Customer, with Supplier having the option to adjust the Priority.
The parties may, at the request of the Client, agree to temporarily deviate from Office Hours and purchase additional Availability, such as during the execution of projects and/or releases.
Scope and types of Calls
The type of Call primarily covered by the SLA and to which the terms of the SLA apply is an Incident. This is an error in the software, link or data which disrupts the normal operation of the Service or produces unwanted results. There are three categories in this:
- Incidents, fixing them;
- Privacy and security Incidents and malfunctions;
- Correction requests, correcting damaged data or links where the cause is Supplier.
Secondary Calls are not covered by the SLA terms but will be handled by Supplier. This includes:
- Restore requests, restoring Backups.
- Questions, answering questions from functional management;
- Consulting, hiring for training;
- Request for Changes (RFCs), requests for software modifications;
- Any other questions and/or requests that are not directly related to the AI-as-a-Service.
Client shall indicate the type of Call when registering a Call. It is up to Supplier to check this and change it if necessary. Secondary Calls are normally paid assignments, apart from RFCs that can be built generically by Supplier. The request to restore a Backup where the cause of the need for a Backup does not lie with Supplier is also a paid assignment.
12. Complaints and communication matrix
If there are Service Complaints, they can be passed on to the assigned Customer Success Manager of Supplier. Support records the Complaint and assigns it to a handler. Customer will be kept informed of the progress. After Acceptance of the complaint report by Customer, the report is considered resolved and the report is closed. If there is no resolution and/or if the Complaint is sensitive it can be discussed in a higher echelon. An escalation may be reported to Supplier's Customer Success Manager at the time a Report is not satisfactorily addressed/resolved. If there is reason to escalate to another level it can be done according to the communication model below.
13. Incident Management
The goal of incident management is to ensure that the Acceptance Assistant is operational again as soon as possible. Incident management is not about fixing the cause.
- Incidents are handled based on Priority and turnaround time. Incidents with a higher Priority always have priority;
- An Incident is considered resolved if Supplier realizes a (temporary) solution that restores the agreed operation.
The order of handling Incidents reported to Supplier shall be determined by Supplier subject to the prioritization described in this section. It may happen that Supplier notices an Incident earlier than Customer. If it is a Priority 1 Incident, Supplier shall notify its Partners immediately via written notification. If it persists for more than 4 hours, an update will be provided via email, including a report on the cause and resolution.
Client can assign an urgency level when reporting an Incident. When reporting an urgency "prio 1" you must make this known to Support by telephone before sending a written report toonesurance This is to ensure a "warm" transfer, so that the urgency is immediately known within Supplier. The Standards regarding urgency are included below:
Description | Urgency | Example |
Prio 1 | Critique | The Services are no longer usable and a workaround is not possible. |
Prio 2 | High | Normal execution of part of the Service is not possible, impact is significant. |
Prio 3 | Medium | The Services do not work completely but there is no further business impact. |
Prio 4 | Low | An Incident that occurs where there is no business impact. |
The notifier can provide the Priority of the Incident, it is checked by Support based on the above conditions and conformed or modified.
Response & Handling Time
For a Priority 1 Incident, Supplier will provide a structural solution or realize a workaround acceptable to Customer. This means that Supplier will keep to its best efforts obligation until the functionality is normally available again, or the urgency is scaled down to prio 2 or 3.
For prio 2 and 3 Supplier can decide to handle further handling of a Call according to planning. This is reported in the handling of the Call by means of a schedule. This is for example the case with bug fixes in application and/or interfaces.
Supplier applies the following criteria and lead times with respect to the resolution of Incidents. As soon as it is clear that the resolution of an Incident cannot be achieved within the agreed resolution time, Supplier, in consultation with the notifier, takes the decision to initiate the escalation procedure.
Priority | Response time | Handling time | Standard |
Prio 1: critical (during Office Hours) | < 60 minuten | < 48 uur | 95% |
Prio 2: high (during Office hours) | < 4 uur | < 72 uur | 95% |
Prio 3: medium (during Office Hours) | < 1 Werkdag | < 20 Werkdagen* | 95% |
* Prio 3 bugs are generally resolved faster, but when development work is required it is scheduled and delivered on the next sprint. In doing so, the latest lead time is 20 Working Days.
For items lower than a prio 3, no Handling Time applies as these are not blocking issues. As a rule, these items go along with the development speed of Priority 3 Incidents.
15. Change Management
Changes within the Acceptance Assistant environment are organized into 3 categories:
1. Changes to optimize Acceptance Assistant on a functional and/or technical level is initiated by Supplier. These are Modifications with the purpose of adding functionalities to the environment and/or eliminating Problems;
2. Calls classified as RFC to make a modification at the request of Client, this can be to add or modify a functionality, but also to perform a restore;
3. Standard Changes, these are modifications that do not impact existing functionality.
Similarly, Modifications may only be submitted by Customer's project supervision. If costs are involved in the modification, Supplier will only implement the Modification after written approval from Customer. Submission of Changes should be done through the Service Desk as described in section '4.1 Support Requests'. The change process after development is included below in section '5.3 Software release'.
16. Software release
Supplier uses continuous integration, so there is a possibility to transfer delivered changes, which have a higher urgency, directly to the production environment. Less urgent changes that are delivered will be delivered in accordance with agreements made in advance. When delivering a release, Supplier releases release documentation up to a maximum of 1 week after the release. This documentation describes what changes, relevant to the Customer, are included in the next release. After the software release, Supplier performs testing, but the Partner is also expected to test on the Acceptance environment if present, and after the release on the Production environment. It is possible to request new functionality or a software modification from Supplier. This can be done by submitting a Request for Change (RFC) to the Customer Success Manager. The Customer Success Manager also provides feedback on the request whether it has been approved, or rejected.
17. Legal requirements
Supplier is bound by laws and regulations. We adapt our software to this in a timely manner, so that Customer can also comply with it in a timely manner. These legal Changes are delivered by a software release in the AI-as-a-Service.
18. Problem management
The goal of problem management is to reduce the likelihood and impact of Incidents by identifying actual and potential causes of Incidents, and managing workarounds and known errors.
Problem identification is initiated from the following situations:
1. All reports related to Incidents that cannot be resolved immediately, but for which a workaround is available, are qualified as a Problem;
2. Incidents that occur more frequently but cannot be resolved immediately and for which no workaround is available are qualified as a Problem;
3. Supplier periodically analyzes the number of notifications coming in, both from Client and internal monitoring. By classifying and grouping the notifications, the AI-as-a-Service recognizes trends. These trends may indicate structural Problems/uncertainties for Client and/or in the technology. Based on these trends, Supplier investigates the cause and comes up with a structural solution. The solution will reappear in a subsequent release;
4. Supplier is responsible for realizing a workaround, Customer is responsible for testing and Accepting the workaround.
19. Security and hosting
Security Supplier makes every effort to keep its Services secure through security measures. Supplier does this from infrastructure to application. In the event of a Security breach, Supplier reserves the right to immediately disable the AI-as-a-Service to limit any claim . Supplier makes every effort to identify and resolve the cause. Supplier logs a prio critical Incident for this and also handles it in accordance with this process.
Security testing If Customer wishes to perform security testing on the AI-as-a-Service, Customer must request permission from Supplier. Supplier asks this in order to prevent unexplained notifications from following at its premises, which could lead them to take measures detrimental to the continuity of one or more customers. The test can be scheduled in consultation. Supplier will in all cases cooperate with such requests. The costs for security testing will be borne by Customer. The summary of this will be shared and is also available by email upon request. In addition, there is an active 4-eye principle on all code going to the production environment.
Data processing Supplier, as a processor, never processes data for purposes other than those agreed upon and for which a legal basis exists. Furthermore, data is never stored by Supplier at locations outside the European Union. This applies to both hosting and disaster recovery locations.
The Service are hosted at Microsoft's Azure Cloud Services. These are designated as sub-processors by Supplier in the processor agreement. For more information on Microsofts Azure certifications, see https://learn.microsoft.com/en-us/azure/compliance/.
20. Redundancy and Backup
For Backups, Onesurance uses the Backup policy as provided by Microsoft Azure. More information about this policy can be found at: https://learn.microsoft.com/nl-nl/sql/relational-databases/Back-up-restore/backup-overview-sql-server?view=sql-server-ver16. Supplier is responsible for creating database Backups and testing for integrity. Backups of the primary data center are performed according to the following schedule:
Type of Backup | Surroundings | Type | Frequency | Retention period |
Database | Production | Full | Daily | 1 week |
Production | Differential | Every 24 hours | 4 weeks | |
Production | Transactional | Every 10 min. | 3 months |
The Backup is then handled in the following manner:
Service | Service Level |
Archiving location | Based on Zone Redundant Storage |
Backup window | Out of Office Hours |
Redundancy | No processed data is stored on the Onesurance side. In the event of a critical situation, the hosting for the API will be re-established and deployed, or a recent Backup of this environment restored. |
RPO | 8 working hours |
RTO | 24 hours |
Location | Address |
MS West Europe | Cultuurweg 11, 1775 RA Middenmeer, The Netherlands |
To ensure that the environment is recoverable, Supplier periodically (1x per year) performs a full recovery recovery action. To ensure that the environment is functionally usable after the recovery action, Supplier involves one or more Partners in this. A report is also made of this action, making it demonstrable for all Supplier's Partners and end customers and audit that we have performed this action. This will be discussed further during tactical consultations.
21. Technical architecture
AI-as-a-Service environments are deployed with a combination of a number of Azure tools:
- Azure DevOps (for orchestrating the process from code to application in the cloud);
- Azure Machine Learning (for storing the model);
- Azure App Service (for hosting the API) and Terraform (for defining the Azure infrastructure in code templates). The code can be found in Azure DevOps.
In order to securely test modifications to the model and API, there are two endpoints (URLs) for the API that can be used. This is a functionality of Azure App Service called "deployment slots." This makes it easy to run two versions of the model side by side in the cloud.
22. Monitoring, detection
Supplier has active monitoring and detection on both servers and software. This means that possible improper login attempts by malicious parties are actively monitored. In case of irregularities, automated alerts are sent to Support by return. These alerts are always considered a Prio 1 Incident, which means that appropriate action can be taken immediately.
23. Information Security
Information security is an important component within Supplier. Because sensitive information is stored and processed, we have a number of important processes in place to ensure the integrity of the data.
24. Information security structure
Supplier is actively engaged in information security and its control. For both application maintenance and operations, there are a number of people responsible for overseeing and monitoring this. The Data Protection Officer role is an executive and internal role. The Data Protection Officer ensures proper Implementation and monitoring of applicable laws and regulations and resulting obligations. The Data Protection Officer advises the management of Onesurance and writes information security policies with them. Within Onesurance , this role also includes monitoring the implementation of the policy in the organization and execution.
25. Data incidents
When a Data Breach is suspected, the Data Protection Officer is called in immediately. The Data Protection Officer investigates the reported Incident together with the Heads of Engineering and Machine Learning and, within 24 hours of suspicion of a Data Breach, reports back to the Client via Support whether a Data Breach has occurred. If so, an Incident Report (see Section 7.3) is prepared and, if necessary, relevant agencies are notified. A comprehensive report will be made and Supplier will conduct in-depth investigation to determine the cause, identify areas for improvement and create an action plan describing how similar situations will be prevented in the future. Implementation of this action plan will commence immediately after the Data Breach has been sealed.
26. Incident Report
When a Data Breach occurs, an incident report is prepared and shared with the Incident reporter and all stakeholders involved in the Incident. An incident report consists of the reporting of the Problem, its cause, impact and resolution. The Problem is remedied as soon as possible and the recipients of the incident report are kept informed. The Data Protection Officer oversees proper handling, resolution of the Incident and aftercare. In the aftercare, Supplier will investigate ways to prevent a similar situation from occurring again and will report this to in the Incident Report.
27. OTAP Street
If agreed with Customer, Supplier will use OTAP methodology for software development. In this way a clear distinction is made in the different environments. The development team works in the development environment, Supplier consultants test in the test environment, the Partner tests in the acceptance environment and the Users work in the production environment. Split environments and databases are used so that no data Incident can occur due to mixing of data across environments.
Table of contents
1. Introduction
2. Validity Terms and Conditions
3. Modification of Terms and Conditions
4. Duration of AI-as-a-Service.
5. License and additional services
6. Delivery Terms
7. Maintenance and failure
8. Warranty Limitation
9. Rate base
10. Billing
11. Adjustment agreement
12. Termination of Agreement
13. Liability
14. Intellectual property rights
15. Privacy & confidentiality
16. Legal Affairs
1. Introduction
We would like to inform you about what you can expect from us when using our AI-as-a-Service. These terms and conditions are written in understandable language to ensure transparency. If there are ambiguities, we are open to your questions.
2. Validity Terms and Conditions
These Terms are part of our agreement and apply during the term, including any renewals.
3. Modification of Terms and Conditions
The most recent version of the Terms and Conditions is always applicable. Changes are communicated in a timely manner and customers have the option of not accepting them, with two months' notice under the old terms.
4. Duration of AI-as-a-Service.
The agreement is for an indefinite period, unless otherwise agreed. The notice period for customers is two months before the new annual period, while we have a notice period of six months for proportionality. With our AI-as-a-Service, you receive a license to use our software and the right to additional services. For this license and services, we charge the agreed rate and you will receive an invoice each month.
5. License and additional services
The AI-as-a-Service includes the product components you purchase based on the rate base (numbers of policies). In addition, you pay a fixed amount per month for Hosting & Computing power. The components can be found on your invoice. You may only use the license for your own organization or its subsidiaries. In addition to the license to use our software, the AI-as-a-Service also entitles you to the following additional services:
- troubleshooting and support during the first three months, as long as it does not exceed 100 support hours;
- continuous monitoring of the software and implementing new releases;
- at least once a year, a periodic report including discussion with the Client's MT;
- consultancy to the extent specifically stated.
If you need additional services, not mentioned here, we are happy to provide them. In that case, we will indicate to you what costs we will charge for it, if any.
6. Delivery Terms
We believe it is important to keep our commitments. But sometimes there are unforeseen circumstances or we depend on third parties. Therefore, all deadlines specified by us are intended to be indicative; the mere exceeding of a specified deadline does not put us in default. In all cases in which exceeding a deadline is imminent or a deadline is not met, we will consult with each other as soon as possible and set a reasonable deadline to still fulfill all obligations properly.
7. Maintenance and malfunction
We may take all or part of the implementation of the AI-as-a-Service out of service for maintenance. We will not take our service out of service for longer than necessary and will do so outside of business hours if possible. Failures we will of course resolve as quickly as possible. For response times, please refer to the Service Levels in our Terms of Service.
8.Warranty limitation
AI predictions are based on statistical models and are provided on a best-effort basis. Onesurance assumes no liability for predictions not coming true or for decisions made by the Client based on these predictions.
9. Rate base
For the license fee, we work on the basis of the number of policies in your portfolio, for which we make a forecast. There is a fixed amount per policy per year for each product component. The rate base is the number of policies rounded down to ten thousand. Once a year, the rate base is redetermined and we increase or decrease the rate based on the numbers. We index rates annually, taking into account the Consumer Price Index (CPI) figure for the previous year, the annual change from July of the current year. The indexation takes effect from the first invoice in the following calendar year. We will inform you of the indexation each time.
10.Billing
Rates are indexed annually in accordance with the CBS CPI figure (year-on-year July). When expanding the number of policies, Onesurance may adjust the rate proportionally. We invoice the license per month in advance. You will receive all our invoices by email in pdf format. The payment period is thirty days.
11. Adjustment agreement
Adding product parts can be done at any time. Removing product items can only be done one year after full billing or at the end of the initial period if agreed upon. Please note that you must make a change and/or termination request one month prior to the new billing period and you cannot increase and decrease within the same quarter.
12.Termination of Agreement.
You can always cancel the license one year after full billing. Please note that you must notify us in writing or by email two months before the expiration of the new annual period. You can terminate the license mid-term within ten business days after the expiration of the initial three-month period. Upon termination, you will no longer have access to the software and associated data. Your data will be deleted within fourteen days. Our notice period is twelve months. We can terminate the agreement immediately if you fail to meet agreements and we have given you notice of default, pay invoices structurally late, or have not paid a non-dispute invoice after 60 days. We also have this right if you have filed for suspension of payment or bankruptcy. After termination of the agreement, data will remain available for export by the Client for 30 days, unless otherwise agreed in writing.
13. Liability
We make every effort to ensure that our software meets the specifications we specify. If errors do occur, we fix them as quickly as possible. We want our software to work optimally, and our service must also be good. Still, things can go wrong. If you have a claim as a result, we will work together to find an appropriate solution. If you have a complaint or claim, it is important that you report it to us as soon as possible. We can then work immediately to find a solution. Moreover, we must also report a claim to our carrier. Whatever goes wrong, we always want to find the right solution by mutual agreement. Our total liability due to an attributable failure in the performance of the agreement or on any legal ground whatsoever is limited to compensation of direct claim up to the amount of the price stipulated for that agreement (excluding VAT). If the agreement is primarily a continuing performance agreement with a term of more than one year, the price stipulated for that agreement shall be set at the total of the fees (excluding VAT) stipulated for one year. In both situations our maximum cumulative liability is limited to EUR 50,000. We can only be held liable for compensation of direct claim and not for any form of consequential damage. Consequential damages include in any case lost sales, lost profits, loss of data and missed opportunities. Neither of us shall be liable to each other in the event of force majeure within the meaning of the law. This also applies to force majeure of suppliers, power grid failures and failures that impede data traffic if the cause is not attributable to the parties themselves. In the event of intent or deliberate recklessness on the part of our company and/or our executive employees, we cannot invoke the limitations of liability.
14. Intellectual property rights
The intellectual property rights to the software are and remain with us. If a third party claims otherwise, we will indemnify you. The condition is that you inform us as soon as possible, cooperate in the investigation and let us handle the case. If the court finds that the intellectual property does indeed belong to a third party, we will ensure that you can continue to use the software or we will offer equivalent software. You are granted a non-exclusive, non-transferable, non-pledgeable and non-sublicensable right to use our software including use of our algorithms during the term of the agreement. It is not permitted to reproduce, disclose, reverse engineer, decompile or make available and/or make available to third parties for inspection, in whole or in part, the software and/or algorithms and/or our documents and materials without prior written permission. The data provided by Client shall remain the property of Client. Client grants Onesurance a right of use for the duration of the agreement to process this data for the purpose of service provision, quality improvement and benchmarking, provided it is anonymized.
15. Privacy & confidentiality
We will comply with all applicable requirements of the General Data Protection Regulation. We warrant to each other that all information, which we reasonably understand to be confidential or competitively sensitive, that we receive from each other before and after entering into the agreement will remain confidential. We will take all reasonable steps to protect such information. We would like to be able to mention in advertising or marketing activities that you are one of our valued clients. In doing so, we will carefully remove from the information to be used or published any information relating to your results and/or the work you have performed that could trace back to you.
16. Legal Affairs
All disputes arising out of or in connection with our agreement shall be submitted exclusively to the judgment of the competent court in Breda, the Netherlands. Our agreement, as well as all disputes related to or arising from our agreement, shall be governed exclusively by Dutch law. The United Nations Convention on Contracts for the International Sale of Goods (Vienna Sales Convention) shall not apply. Notices which we give to each other under this agreement shall be in writing. Written means by mail and/or e-mail, if addressed to the e-mail addresses of the signatories of the agreement. Any oral promises and agreements have no effect unless confirmed in writing by both parties.
17. Partner Strategy and Training
Implementation partners can be certified through a training program. Paid onboarding and training modules available to increase efficiency and adoption.
Contact details Onesurance B.V.
Visiting address: Rithmeesterpark 50 A1, 4838 AZ Breda | Basisweg 32, 1043 AP Amsterdam
Email: onesurance
Website: onesurance
Chamber of Commerce: 87521997
IBAN: NL25 INGB 0398 4072 82
VAT:NL 8643.18.315.B01
Terms of service Onesurance
1. Introduction
The parties wish to qualitatively manage each other's expectations and obligations regarding the performance of the services as described in the Agreement. In any cooperation, success depends on correct and timely mutual cooperation. Among other things, it is important that the Parties communicate clearly on both sides, with (important) information being shared in a timely manner.
This SLA sets forth the arrangements for the performance of the Service.
Agreement
The parties have an Agreement to use Onesurance s AI-as-a-Service (hereinafter "Agreement"). This Service Level Agreement (hereinafter referred to as the "SLA") is a part of this Agreement.
Applicability
This SLA applies to the production environment of Onesurance s AI-as-a-Service and associated portals and links. In addition, if agreed, an acceptance environment is available, terms and conditions for this are listed separately.
Purpose SLA
The SLA establishes agreements on service quality parameters with the aim of monitoring and reporting on the quality and performance of the service of both the product and support. The SLA covers the Availability of the AI-as-a-Service, the Backup and ongoing Availability of data, as well as the continuity of services from Onesurance. This includes the Services of Support.
Changes to existing SLA
This SLA is a living document to be reviewed and updated periodically to continue to meet the needs of both Parties. All enhancements will be made unilaterally. If a modification may have a negative impact on the Client, Onesurance will do so by mutual agreement and only after Client's approval.
Definitions
Capitalized terms shall have the following meaning or the meaning as provided elsewhere in this document:
Acceptance:
Customer's final and written approval of (parts of) the Service(s).
Handling time:
The time measured and recorded by Supplier (including Response Time) between:
- The time of reporting the Incident to Supplier and Supplier's notification to Customer that the Incident has been remedied;
- The time at which this is demonstrably reported by Supplier;
- The time the Service is available again.
Backup: a copy of files, data held on a data carrier to restore this information in the event of a system crash, data loss or other calamity.
Availability: time period expressed as a percentage of the total time measured over a full calendar month in which a Service is available under the appropriate conditions.
Call: a message (by phone/e-mail) from a person in Client's organization or a notification from Onesurances monitoring system.
Data Breach: a breach of confidentiality and/or of the integrity and/or of the Availability of Personal Data where unauthorized persons have inadvertently or unauthorizedly gained access to (client) Personal Data This may result from a variety of causes, such as a cyber-attack, human error, technical failure, or technical error. A Data Breach may result in the unauthorized access to, disclosure of, alteration of, or loss of personal data.
Service(s) means all work to be performed by Supplier on behalf of Customer under this Agreement, including all Services, functions and responsibilities not specifically described in this Agreement, but necessary for the proper and/or lawful performance and delivery of the described Services, functions and responsibilities.
Downtime: the period during which the Service is unavailable or unresponsive at all.
Holidays: national Holidays determined by the government and the days on which Supplier has announced to be closed. These days shall not be counted as a Working Day.
Users: the persons employed by or working for the Client and/or using the Acceptance Assistant because they are clients/clients of the Client.
Scheduled Unavailability: the period(s) during which Acceptance Assistant is unavailable due to scheduled and pre-announced (maintenance) work.
Implementation: the whole of actions and measures necessary to put all parts of the Services and supplied software, separately and in mutual coherence, into use in the organization of the Client, in such a way that all Users of the Client can work with it in accordance with the agreed use. If agreed, the Implementation also includes the conversion, the realization of the links necessary for the agreed use and the execution of the acceptance procedure.
Incident: an interruption, deviation, disruption, reduced Availability or reduced speed of an agreed upon service, resource or product.
Office Hours: the period during which Supplier can be reached on the Business Days.
Complaint: (written) expression of dissatisfaction with Supplier's services.
Supplier: Onesurance.
Maintenance Window: time period during which maintenance can be performed on the managed components.
Non-Availability: the periods when Acceptance Assistant is not accessible to the authorized Users in accordance with the agreed functionality as agreed in the service description.
Standard: the percentage of successful incident settlements within the promised times that Acceptance Assistant must meet as a minimum.
Client: the client of Onesurance.
Agreement: the Agreement and attachments
Force Majeure: unforeseen and uncontrollable circumstances beyond a Party's control that may adversely affect performance of the Service. Examples include natural disasters, terrorist activities, power outages, strikes, or other events beyond the reasonable control of that Party.
Parties: Contractor and Supplier jointly referred to as "Parties" and separately referred to as "Party",
Partner: the customer of Supplier, who purchases the Services and/or application from Onesurance .
Priority: the degree of urgency of the Incident, as described in Chapter 5.
Problem: Failure to comply due to an initially unknown cause which may lead to one or more Incidents.
Response Time: the time between receiving a report and when it is acted upon (registration, first contact with Client and start of diagnosis).
Recovery Point Objective (RPO): the maximum period during which data loss is acceptable in the event of a disaster.
Recovery Time Objective (RTO): the maximum time between an Incident and functionality being available again
Request for Change (RFC): a request from Client to change, add or remove a functionality.
AI-as-a-Service: Onesurance s application made available to authorized Users via the Internet.
Security breach: an Incident in which unauthorized persons gain access to data, applications, networks or devices without permission. This can lead to Data Breaches, loss of confidential information or other negative consequences for individuals or organizations.
Support: Supplier's central point of contact for Customer's Users.
Service Level: the level of a partial aspect of the Service(s) to be delivered by the supplier, expressed by means of an indicator.
Service Window: the time frame within which the Service(s) is/are performed.
Fee(s): all Fees agreed upon for the Services.
Working Days: a day falling within Supplier's Office Hours.
Change: a change carried out on (parts of) a Service or infrastructure, with such an impact (potentially) that a careful assessment should precede its introduction.
2. General AI-as-a-Service
Supplier makes its AI-as-a-Service available via the Internet and provides technical maintenance and management of the Services provided. Supplier makes its products available from an EEA-based data center. In order to make use of this, Customer must take care of a:
- Stable Internet connection with speed of at least 5Mbps;
- Chrome browser, equipped with the latest updates;
- Resolution of at least 1600 x 900 combined with a scale of 100%.
The Service is an AI-as-a-Service application and therefore has the following benefits and conditions:
- Client does not have to purchase the software and hardware on which this software is installed, but pays for the use of the AI-as-a-Service;
- Client accesses the AI-as-a-Service via a secure Internet connection;
3. Technical management by Onesurance
Technical maintenance and management will be provided by Supplier. This includes Infrastructure management, Data management, Security management, Compliance & audits and Performance optimizations. Of course, Supplier also takes care of the delivery of new functionalities in the application.
Infrastructure: Managing the hardware infrastructure, such as hosting, servers, and storage, required to support the AI-as-a-Service application.
Data Management: Managing the data stored and processed by the AI-as-a-Service application. This includes implementing, managing and monitoring Backup and Recovery procedures, ensuring data integrity and meeting data protection compliance requirements.
Security Management: Implementing and maintaining security measures to protect the AI-as-a-Service application from threats such as hackers, malware and Data breaches. This includes monitoring security events, performing penetration tests and implementing access control mechanisms.
Service Support: Providing technical support to end users of the application. This includes taking Incidents, handling RFCs and possibly providing paid training.
Compliance and Audits: Compliance with legal and industry compliance requirements such as the AVG, and standards around information and cyber security. In addition, Supplier shall cooperate with annual audits and PEN testing to ensure that the application complies with applicable laws and regulations at all times.
Performance maintenance and optimizations: Managing the systems and identifying opportunities for improving the performance of the AI-as-a-Service application, such as optimizing code and data processing.
Delivery of new functionalities: If new functionalities are needed then Customer can indicate this to Supplier and it will be built by Supplier at an agreed upon cost.
Functional Management Supplier is responsible for the functional management of the Service. This includes Accepting and processing user questions, Maintaining the facility, Performing periodic checks on the operation of the facility, Delivering data and requirements to Customer and collecting user feedback.
Acceptance and processing of user queries: The questions asked by end users must be accepted and processed by the Supplier. If the Customer notices that something is a bug then this can be submitted to Support of Supplier and it will be resolved. New functionalities (RFC) can be submitted via the Customer Success Manager. Generic RFCs are implemented free of charge, for Partner specific requests a Fee is requested which is communicated in advance.
Maintain Setup: The proposal includes an initial setup of the application by Supplier.
Delivery of data and requirements: If Client wants to migrate data, have a new link or request new functionality, then Client is responsible for delivering this information. For links, Customer is responsible for preparing the requirements, collecting the necessary information and credentials, and fully testing and approving the link. Supplier is not responsible for any errors in a prepared and agreed setup.
Collecting User Feedback: Client is responsible for collecting user feedback. With this feedback, Client will improve the user experience by requesting an RFC from Onesurance.
Functional Chain Testing: It is the responsibility of the Client to conduct regular chain tests, testing the functional operation of the application and links. These chain tests serve to ensure the quality of the setup and the integrity of the data. The purpose of this is to ensure that the system functions optimally and meets the specified functional requirements. These requirements can only be checked by the Client itself, as well as the authenticity of the data.
4. Application performance.
To work well with AI-as-a-Service, a fast-working application is very important. Of course, speed depends on several factors, including a well-functioning (Wi-Fi) network. Under optimal conditions, we aim for the following performance, excluding scheduled maintenance and Force Majeure, on a best-effort basis:
Type | Measuring point | Measurement time | Standard performance | Standard |
Availability | Uptime percentage | Monthly | 95% accessibility | 90% |
Speed | Frontend load time | When loading a page | 3 sec | 90% |
Capacity | Number of simultaneous users | During peak load | Max 50 users | 90% |
Recovery time | Time to resolve critical failures | After a critical failure | 48 hours | 90% |
It is the responsibility of the Client to ensure that the environment is regularly cleaned and maintained so that unnecessary data is removed and the system performs optimally without delays due to overload or redundant information that would prevent the above times from being met.
5. Availability of production environment AI-as-a-Service
Supplier commits to an Availability of at least 95% for its AI-as-a-Service, less Planned Unavailability. The performance indicators issued relate to Supplier's service(s) in a production environment and do not apply to Services in an acceptance environment. Availability is calculated per calendar month according to the formula:
Uptime = { ( T - D ) / T } * 100% T: Service Window per month D: Total Unavailability (Downtime) Downtime in a Maintenance Window, is excluded from the calculation. |
Our principles around Availability are:
1. Work that has an impact on the Availability of the AI-as-a-Service will be performed outside Office Hours as much as possible, about this maintenance Supplier will inform Customer in writing at least 7 days in advance. In exceptional situations the Supplier may have to perform these activities within Office Hours, this will only be done in case of high priority and after consultation with Customer.
2. Non-Availability due to the reasons and causes below cannot be attributed to Supplier and is therefore outside the Availability:
a) Maintenance work agreed with Customer in writing during the Maintenance Window
(b) Incidents due to Force Majeure.
6. Availability of acceptance environment AI-as-a-Service
If desired by Customer, Supplier will provide the possibility of setting up an acceptance environment. This will be discussed during the project phase and if necessary set up by Supplier, who will also be responsible for maintaining the environment. Supplier commits to an Availability of the acceptance environment of at least 85% for its AI-as-a-Service, less the Planned Unavailability. The Acceptance Environment Availability is lower than the production environment because test scenarios are regularly rolled out for our Partners, allowing for extensive testing before items go to production. The performance indicators issued relate to Supplier service(s) in an acceptance environment and do not apply to Services in a production environment. Availability is calculated per calendar month according to the formula:
Uptime = { ( T - D ) / T } * 100% T: Service Window per month D: Total Unavailability (Downtime) Downtime in a Maintenance Window, is excluded from the calculation. |
The principles around Availability for the acceptance environment are:
1. The acceptance environment will be updated with the new functionalities after consultation and by arrangement.
2. If an update needs to be implemented earlier then this will be discussed and implemented by mutual agreement at a time when the impact to Client is minimal.
3. Important updates are carried out during the day after the Client has been informed of them in a timely manner and has been able to take measures, if necessary, as a result, the application may be temporarily unavailable.
7. Measuring Availability.
To proactively measure Availability, Supplier uses:
- Monitoring of servers to measure whether they are active;
- Monitoring the AI-as-a-Service for activity and environmental load;
- Number of successful login checks on the AI-as-a-Service;
Login control principles:
- Login control assumes one login attempt per minute within the Service Window;
- Login attempts during the Maintenance Window are ignored.
A printout of non-sensitive information such as Availability in percentage can be provided upon request.
8. Monitoring the environment
Like the infrastructure, our AI-as-a-Service solutions and associated portals are monitored 24x7. If disruptions occur in the underlying infrastructure or on the application, the Supplier receives an automated notification. Supplier attempts to resolve the disruption immediately. Service Window
Supplier guarantees within the Service Window an Availability according to the Standard below.
Description | Availability | Note |
Service Window | 8:30 - 17:30 Monday through Friday | Exclusive Maintenance Window |
Maintenance Window | Announced and planned | If necessary with advance notice |
Standard Availability | 95% | Per month within the Service Window |
The Maintenance Window allows Supplier to perform scheduled maintenance on predetermined time frames.
Description | Availability | Note |
Maintenance Window | Announced and planned | Potential impact on Availability or Performance* |
*Maintenance with impact on Availability will be announced in writing at least 7 Business Days in advance, unless there is a security incident and/or urgent Change. In the latter case, Supplier will contact Customer's contact person here as soon as possible. If it is foreseen that an urgent Change may cause a conflict with regular maintenance in the Maintenance Window, Supplier will first perform the urgent Change and if possible after that the regular maintenance. If it is not possible to perform the regular maintenance, another time will be scheduled for this regular maintenance. The priority is always to implement the urgent Change. In order to guarantee the service it is important to implement relevant updates in a timely manner. Supplier therefore implements the new security updates according to the deadline below.
Rating | Lead time | Explanation |
Not critical | < 3 maanden | A (security) Incident that occurs where there is no business impact |
Medium Priority | < 1 maand | A (security Incident that occurs where the business impact is minimal and there is no risk of data breach. |
High Priority | Per direct, < 72 uur | A (security) Incident that occurs where a business impact is possible. |
Critique | Per direct, < 48 uur | A (security) Incident that occurs where a business impact is significant. |
9. Responsibilities testing after maintenance
Supplier is responsible for the uptime of the application and technology. After maintenance, Supplier will therefore perform a check on the operation of the functionalities. If any Changes are made in the setup of the application, Customer will be notified in advance by email. It is the Supplier's responsibility to perform a functional test after an update to check whether functionality still works as initially intended. Links are not modified without mutual consent (if the operation of the link changes) and are therefore outside the scope for testing after maintenance. Updating the acceptance environment, testing and release to production is always done based on pre-communicated planning from Supplier.
Support services
Support Requests
Supplier provides support on its AI-as-a-Service. For this purpose, Support from Supplier is available to answer and handle service requests (Calls). Service Requests may only be notified by Customer's project support. Telephone accessibility for this support is during Office Hours.
Service Desk service | Days | Period |
Support: +31 6 132 70 144 | Mon to Fri* | 08:30-17:30 a.m. |
*excluding Holidays
Reports that are posted are picked up within Office Hours based on Priority. The Priority is initially specified by Customer, with Supplier having the option to adjust the Priority.
The parties may, at the request of the Client, agree to temporarily deviate from Office Hours and purchase additional Availability, such as during the execution of projects and/or releases.
Scope and types of Calls
The type of Call primarily covered by the SLA and to which the terms of the SLA apply is an Incident. This is an error in the software, link or data which disrupts the normal operation of the Service or produces unwanted results. There are three categories in this:
- Incidents, fixing them;
- Privacy and security Incidents and malfunctions;
- Correction requests, correcting damaged data or links where the cause is Supplier.
Secondary Calls are not covered by the SLA terms but will be handled by Supplier. This includes:
- Restore requests, restoring Backups.
- Questions, answering questions from functional management;
- Consulting, hiring for training;
- Request for Changes (RFCs), requests for software modifications;
- Any other questions and/or requests that are not directly related to the AI-as-a-Service.
Client shall indicate the type of Call when registering a Call. It is up to Supplier to check this and change it if necessary. Secondary Calls are normally paid assignments, apart from RFCs that can be built generically by Supplier. The request to restore a Backup where the cause of the need for a Backup does not lie with Supplier is also a paid assignment.
12. Complaints and communication matrix
If there are Service Complaints, they can be passed on to the assigned Customer Success Manager of Supplier. Support records the Complaint and assigns it to a handler. Customer will be kept informed of the progress. After Acceptance of the complaint report by Customer, the report is considered resolved and the report is closed. If there is no resolution and/or if the Complaint is sensitive it can be discussed in a higher echelon. An escalation may be reported to Supplier's Customer Success Manager at the time a Report is not satisfactorily addressed/resolved. If there is reason to escalate to another level it can be done according to the communication model below.
13. Incident Management
The goal of incident management is to ensure that the Acceptance Assistant is operational again as soon as possible. Incident management is not about fixing the cause.
- Incidents are handled based on Priority and turnaround time. Incidents with a higher Priority always have priority;
- An Incident is considered resolved if Supplier realizes a (temporary) solution that restores the agreed operation.
The order of handling Incidents reported to Supplier shall be determined by Supplier subject to the prioritization described in this section. It may happen that Supplier notices an Incident earlier than Customer. If it is a Priority 1 Incident, Supplier shall notify its Partners immediately via written notification. If it persists for more than 4 hours, an update will be provided via email, including a report on the cause and resolution.
Client can assign an urgency level when reporting an Incident. When reporting an urgency "prio 1" you must make this known to Support by telephone before sending a written report toonesurance This is to ensure a "warm" transfer, so that the urgency is immediately known within Supplier. The Standards regarding urgency are included below:
Description | Urgency | Example |
Prio 1 | Critique | The Services are no longer usable and a workaround is not possible. |
Prio 2 | High | Normal execution of part of the Service is not possible, impact is significant. |
Prio 3 | Medium | The Services do not work completely but there is no further business impact. |
Prio 4 | Low | An Incident that occurs where there is no business impact. |
The notifier can provide the Priority of the Incident, it is checked by Support based on the above conditions and conformed or modified.
Response & Handling Time
For a Priority 1 Incident, Supplier will provide a structural solution or realize a workaround acceptable to Customer. This means that Supplier will keep to its best efforts obligation until the functionality is normally available again, or the urgency is scaled down to prio 2 or 3.
For prio 2 and 3 Supplier can decide to handle further handling of a Call according to planning. This is reported in the handling of the Call by means of a schedule. This is for example the case with bug fixes in application and/or interfaces.
Supplier applies the following criteria and lead times with respect to the resolution of Incidents. As soon as it is clear that the resolution of an Incident cannot be achieved within the agreed resolution time, Supplier, in consultation with the notifier, takes the decision to initiate the escalation procedure.
Priority | Response time | Handling time | Standard |
Prio 1: critical (during Office Hours) | < 60 minuten | < 48 uur | 95% |
Prio 2: high (during Office hours) | < 4 uur | < 72 uur | 95% |
Prio 3: medium (during Office Hours) | < 1 Werkdag | < 20 Werkdagen* | 95% |
* Prio 3 bugs are generally resolved faster, but when development work is required it is scheduled and delivered on the next sprint. In doing so, the latest lead time is 20 Working Days.
For items lower than a prio 3, no Handling Time applies as these are not blocking issues. As a rule, these items go along with the development speed of Priority 3 Incidents.
15. Change Management
Changes within the Acceptance Assistant environment are organized into 3 categories:
1. Changes to optimize Acceptance Assistant on a functional and/or technical level is initiated by Supplier. These are Modifications with the purpose of adding functionalities to the environment and/or eliminating Problems;
2. Calls classified as RFC to make a modification at the request of Client, this can be to add or modify a functionality, but also to perform a restore;
3. Standard Changes, these are modifications that do not impact existing functionality.
Similarly, Modifications may only be submitted by Customer's project supervision. If costs are involved in the modification, Supplier will only implement the Modification after written approval from Customer. Submission of Changes should be done through the Service Desk as described in section '4.1 Support Requests'. The change process after development is included below in section '5.3 Software release'.
16. Software release
Supplier uses continuous integration, so there is a possibility to transfer delivered changes, which have a higher urgency, directly to the production environment. Less urgent changes that are delivered will be delivered in accordance with agreements made in advance. When delivering a release, Supplier releases release documentation up to a maximum of 1 week after the release. This documentation describes what changes, relevant to the Customer, are included in the next release. After the software release, Supplier performs testing, but the Partner is also expected to test on the Acceptance environment if present, and after the release on the Production environment. It is possible to request new functionality or a software modification from Supplier. This can be done by submitting a Request for Change (RFC) to the Customer Success Manager. The Customer Success Manager also provides feedback on the request whether it has been approved, or rejected.
17. Legal requirements
Supplier is bound by laws and regulations. We adapt our software to this in a timely manner, so that Customer can also comply with it in a timely manner. These legal Changes are delivered by a software release in the AI-as-a-Service.
18. Problem management
The goal of problem management is to reduce the likelihood and impact of Incidents by identifying actual and potential causes of Incidents, and managing workarounds and known errors.
Problem identification is initiated from the following situations:
1. All reports related to Incidents that cannot be resolved immediately, but for which a workaround is available, are qualified as a Problem;
2. Incidents that occur more frequently but cannot be resolved immediately and for which no workaround is available are qualified as a Problem;
3. Supplier periodically analyzes the number of notifications coming in, both from Client and internal monitoring. By classifying and grouping the notifications, the AI-as-a-Service recognizes trends. These trends may indicate structural Problems/uncertainties for Client and/or in the technology. Based on these trends, Supplier investigates the cause and comes up with a structural solution. The solution will reappear in a subsequent release;
4. Supplier is responsible for realizing a workaround, Customer is responsible for testing and Accepting the workaround.
19. Security and hosting
Security Supplier makes every effort to keep its Services secure through security measures. Supplier does this from infrastructure to application. In the event of a Security breach, Supplier reserves the right to immediately disable the AI-as-a-Service to limit any claim . Supplier makes every effort to identify and resolve the cause. Supplier logs a prio critical Incident for this and also handles it in accordance with this process.
Security testing If Customer wishes to perform security testing on the AI-as-a-Service, Customer must request permission from Supplier. Supplier asks this in order to prevent unexplained notifications from following at its premises, which could lead them to take measures detrimental to the continuity of one or more customers. The test can be scheduled in consultation. Supplier will in all cases cooperate with such requests. The costs for security testing will be borne by Customer. The summary of this will be shared and is also available by email upon request. In addition, there is an active 4-eye principle on all code going to the production environment.
Data processing Supplier, as a processor, never processes data for purposes other than those agreed upon and for which a legal basis exists. Furthermore, data is never stored by Supplier at locations outside the European Union. This applies to both hosting and disaster recovery locations.
The Service are hosted at Microsoft's Azure Cloud Services. These are designated as sub-processors by Supplier in the processor agreement. For more information on Microsofts Azure certifications, see https://learn.microsoft.com/en-us/azure/compliance/.
20. Redundancy and Backup
For Backups, Onesurance uses the Backup policy as provided by Microsoft Azure. More information about this policy can be found at: https://learn.microsoft.com/nl-nl/sql/relational-databases/Back-up-restore/backup-overview-sql-server?view=sql-server-ver16. Supplier is responsible for creating database Backups and testing for integrity. Backups of the primary data center are performed according to the following schedule:
Type of Backup | Surroundings | Type | Frequency | Retention period |
Database | Production | Full | Daily | 1 week |
Production | Differential | Every 24 hours | 4 weeks | |
Production | Transactional | Every 10 min. | 3 months |
The Backup is then handled in the following manner:
Service | Service Level |
Archiving location | Based on Zone Redundant Storage |
Backup window | Out of Office Hours |
Redundancy | No processed data is stored on the Onesurance side. In the event of a critical situation, the hosting for the API will be re-established and deployed, or a recent Backup of this environment restored. |
RPO | 8 working hours |
RTO | 24 hours |
Location | Address |
MS West Europe | Cultuurweg 11, 1775 RA Middenmeer, The Netherlands |
To ensure that the environment is recoverable, Supplier periodically (1x per year) performs a full recovery recovery action. To ensure that the environment is functionally usable after the recovery action, Supplier involves one or more Partners in this. A report is also made of this action, making it demonstrable for all Supplier's Partners and end customers and audit that we have performed this action. This will be discussed further during tactical consultations.
21. Technical architecture
AI-as-a-Service environments are deployed with a combination of a number of Azure tools:
- Azure DevOps (for orchestrating the process from code to application in the cloud);
- Azure Machine Learning (for storing the model);
- Azure App Service (for hosting the API) and Terraform (for defining the Azure infrastructure in code templates). The code can be found in Azure DevOps.
In order to securely test modifications to the model and API, there are two endpoints (URLs) for the API that can be used. This is a functionality of Azure App Service called "deployment slots." This makes it easy to run two versions of the model side by side in the cloud.
22. Monitoring, detection
Supplier has active monitoring and detection on both servers and software. This means that possible improper login attempts by malicious parties are actively monitored. In case of irregularities, automated alerts are sent to Support by return. These alerts are always considered a Prio 1 Incident, which means that appropriate action can be taken immediately.
23. Information Security
Information security is an important component within Supplier. Because sensitive information is stored and processed, we have a number of important processes in place to ensure the integrity of the data.
24. Information security structure
Supplier is actively engaged in information security and its control. For both application maintenance and operations, there are a number of people responsible for overseeing and monitoring this. The Data Protection Officer role is an executive and internal role. The Data Protection Officer ensures proper Implementation and monitoring of applicable laws and regulations and resulting obligations. The Data Protection Officer advises the management of Onesurance and writes information security policies with them. Within Onesurance , this role also includes monitoring the implementation of the policy in the organization and execution.
25. Data incidents
When a Data Breach is suspected, the Data Protection Officer is called in immediately. The Data Protection Officer investigates the reported Incident together with the Heads of Engineering and Machine Learning and, within 24 hours of suspicion of a Data Breach, reports back to the Client via Support whether a Data Breach has occurred. If so, an Incident Report (see Section 7.3) is prepared and, if necessary, relevant agencies are notified. A comprehensive report will be made and Supplier will conduct in-depth investigation to determine the cause, identify areas for improvement and create an action plan describing how similar situations will be prevented in the future. Implementation of this action plan will commence immediately after the Data Breach has been sealed.
26. Incident Report
When a Data Breach occurs, an incident report is prepared and shared with the Incident reporter and all stakeholders involved in the Incident. An incident report consists of the reporting of the Problem, its cause, impact and resolution. The Problem is remedied as soon as possible and the recipients of the incident report are kept informed. The Data Protection Officer oversees proper handling, resolution of the Incident and aftercare. In the aftercare, Supplier will investigate ways to prevent a similar situation from occurring again and will report this to in the Incident Report.
27. OTAP Street
If agreed with Customer, Supplier will use OTAP methodology for software development. In this way a clear distinction is made in the different environments. The development team works in the development environment, Supplier consultants test in the test environment, the Partner tests in the acceptance environment and the Users work in the production environment. Split environments and databases are used so that no data Incident can occur due to mixing of data across environments.
Table of contents
1. Introduction
2. Validity Terms and Conditions
3. Modification of Terms and Conditions
4. Duration of AI-as-a-Service.
5. License and additional services
6. Delivery Terms
7. Maintenance and failure
8. Warranty Limitation
9. Rate base
10. Billing
11. Adjustment agreement
12. Termination of Agreement
13. Liability
14. Intellectual property rights
15. Privacy & confidentiality
16. Legal Affairs
1. Introduction
We would like to inform you about what you can expect from us when using our AI-as-a-Service. These terms and conditions are written in understandable language to ensure transparency. If there are ambiguities, we are open to your questions.
2. Validity Terms and Conditions
These Terms are part of our agreement and apply during the term, including any renewals.
3. Modification of Terms and Conditions
The most recent version of the Terms and Conditions is always applicable. Changes are communicated in a timely manner and customers have the option of not accepting them, with two months' notice under the old terms.
4. Duration of AI-as-a-Service.
The agreement is for an indefinite period, unless otherwise agreed. The notice period for customers is two months before the new annual period, while we have a notice period of six months for proportionality. With our AI-as-a-Service, you receive a license to use our software and the right to additional services. For this license and services, we charge the agreed rate and you will receive an invoice each month.
5. License and additional services
The AI-as-a-Service includes the product components you purchase based on the rate base (numbers of policies). In addition, you pay a fixed amount per month for Hosting & Computing power. The components can be found on your invoice. You may only use the license for your own organization or its subsidiaries. In addition to the license to use our software, the AI-as-a-Service also entitles you to the following additional services:
- troubleshooting and support during the first three months, as long as it does not exceed 100 support hours;
- continuous monitoring of the software and implementing new releases;
- at least once a year, a periodic report including discussion with the Client's MT;
- consultancy to the extent specifically stated.
If you need additional services, not mentioned here, we are happy to provide them. In that case, we will indicate to you what costs we will charge for it, if any.
6. Delivery Terms
We believe it is important to keep our commitments. But sometimes there are unforeseen circumstances or we depend on third parties. Therefore, all deadlines specified by us are intended to be indicative; the mere exceeding of a specified deadline does not put us in default. In all cases in which exceeding a deadline is imminent or a deadline is not met, we will consult with each other as soon as possible and set a reasonable deadline to still fulfill all obligations properly.
7. Maintenance and malfunction
We may take all or part of the implementation of the AI-as-a-Service out of service for maintenance. We will not take our service out of service for longer than necessary and will do so outside of business hours if possible. Failures we will of course resolve as quickly as possible. For response times, please refer to the Service Levels in our Terms of Service.
8.Warranty limitation
AI predictions are based on statistical models and are provided on a best-effort basis. Onesurance assumes no liability for predictions not coming true or for decisions made by the Client based on these predictions.
9. Rate base
For the license fee, we work on the basis of the number of policies in your portfolio, for which we make a forecast. There is a fixed amount per policy per year for each product component. The rate base is the number of policies rounded down to ten thousand. Once a year, the rate base is redetermined and we increase or decrease the rate based on the numbers. We index rates annually, taking into account the Consumer Price Index (CPI) figure for the previous year, the annual change from July of the current year. The indexation takes effect from the first invoice in the following calendar year. We will inform you of the indexation each time.
10.Billing
Rates are indexed annually in accordance with the CBS CPI figure (year-on-year July). When expanding the number of policies, Onesurance may adjust the rate proportionally. We invoice the license per month in advance. You will receive all our invoices by email in pdf format. The payment period is thirty days.
11. Adjustment agreement
Adding product parts can be done at any time. Removing product items can only be done one year after full billing or at the end of the initial period if agreed upon. Please note that you must make a change and/or termination request one month prior to the new billing period and you cannot increase and decrease within the same quarter.
12.Termination of Agreement.
You can always cancel the license one year after full billing. Please note that you must notify us in writing or by email two months before the expiration of the new annual period. You can terminate the license mid-term within ten business days after the expiration of the initial three-month period. Upon termination, you will no longer have access to the software and associated data. Your data will be deleted within fourteen days. Our notice period is twelve months. We can terminate the agreement immediately if you fail to meet agreements and we have given you notice of default, pay invoices structurally late, or have not paid a non-dispute invoice after 60 days. We also have this right if you have filed for suspension of payment or bankruptcy. After termination of the agreement, data will remain available for export by the Client for 30 days, unless otherwise agreed in writing.
13. Liability
We make every effort to ensure that our software meets the specifications we specify. If errors do occur, we fix them as quickly as possible. We want our software to work optimally, and our service must also be good. Still, things can go wrong. If you have a claim as a result, we will work together to find an appropriate solution. If you have a complaint or claim, it is important that you report it to us as soon as possible. We can then work immediately to find a solution. Moreover, we must also report a claim to our carrier. Whatever goes wrong, we always want to find the right solution by mutual agreement. Our total liability due to an attributable failure in the performance of the agreement or on any legal ground whatsoever is limited to compensation of direct claim up to the amount of the price stipulated for that agreement (excluding VAT). If the agreement is primarily a continuing performance agreement with a term of more than one year, the price stipulated for that agreement shall be set at the total of the fees (excluding VAT) stipulated for one year. In both situations our maximum cumulative liability is limited to EUR 50,000. We can only be held liable for compensation of direct claim and not for any form of consequential damage. Consequential damages include in any case lost sales, lost profits, loss of data and missed opportunities. Neither of us shall be liable to each other in the event of force majeure within the meaning of the law. This also applies to force majeure of suppliers, power grid failures and failures that impede data traffic if the cause is not attributable to the parties themselves. In the event of intent or deliberate recklessness on the part of our company and/or our executive employees, we cannot invoke the limitations of liability.
14. Intellectual property rights
The intellectual property rights to the software are and remain with us. If a third party claims otherwise, we will indemnify you. The condition is that you inform us as soon as possible, cooperate in the investigation and let us handle the case. If the court finds that the intellectual property does indeed belong to a third party, we will ensure that you can continue to use the software or we will offer equivalent software. You are granted a non-exclusive, non-transferable, non-pledgeable and non-sublicensable right to use our software including use of our algorithms during the term of the agreement. It is not permitted to reproduce, disclose, reverse engineer, decompile or make available and/or make available to third parties for inspection, in whole or in part, the software and/or algorithms and/or our documents and materials without prior written permission. The data provided by Client shall remain the property of Client. Client grants Onesurance a right of use for the duration of the agreement to process this data for the purpose of service provision, quality improvement and benchmarking, provided it is anonymized.
15. Privacy & confidentiality
We will comply with all applicable requirements of the General Data Protection Regulation. We warrant to each other that all information, which we reasonably understand to be confidential or competitively sensitive, that we receive from each other before and after entering into the agreement will remain confidential. We will take all reasonable steps to protect such information. We would like to be able to mention in advertising or marketing activities that you are one of our valued clients. In doing so, we will carefully remove from the information to be used or published any information relating to your results and/or the work you have performed that could trace back to you.
16. Legal Affairs
All disputes arising out of or in connection with our agreement shall be submitted exclusively to the judgment of the competent court in Breda, the Netherlands. Our agreement, as well as all disputes related to or arising from our agreement, shall be governed exclusively by Dutch law. The United Nations Convention on Contracts for the International Sale of Goods (Vienna Sales Convention) shall not apply. Notices which we give to each other under this agreement shall be in writing. Written means by mail and/or e-mail, if addressed to the e-mail addresses of the signatories of the agreement. Any oral promises and agreements have no effect unless confirmed in writing by both parties.
17. Partner Strategy and Training
Implementation partners can be certified through a training program. Paid onboarding and training modules available to increase efficiency and adoption.
Contact details Onesurance B.V.
Visiting address: Rithmeesterpark 50 A1, 4838 AZ Breda | Basisweg 32, 1043 AP Amsterdam
Email: onesurance
Website: onesurance
Chamber of Commerce: 87521997
IBAN: NL25 INGB 0398 4072 82
VAT:NL 8643.18.315.B01
Terms of service Onesurance
1. Introduction
The parties wish to qualitatively manage each other's expectations and obligations regarding the performance of the services as described in the Agreement. In any cooperation, success depends on correct and timely mutual cooperation. Among other things, it is important that the Parties communicate clearly on both sides, with (important) information being shared in a timely manner.
This SLA sets forth the arrangements for the performance of the Service.
Agreement
The parties have an Agreement to use Onesurance s AI-as-a-Service (hereinafter "Agreement"). This Service Level Agreement (hereinafter referred to as the "SLA") is a part of this Agreement.
Applicability
This SLA applies to the production environment of Onesurance s AI-as-a-Service and associated portals and links. In addition, if agreed, an acceptance environment is available, terms and conditions for this are listed separately.
Purpose SLA
The SLA establishes agreements on service quality parameters with the aim of monitoring and reporting on the quality and performance of the service of both the product and support. The SLA covers the Availability of the AI-as-a-Service, the Backup and ongoing Availability of data, as well as the continuity of services from Onesurance. This includes the Services of Support.
Changes to existing SLA
This SLA is a living document to be reviewed and updated periodically to continue to meet the needs of both Parties. All enhancements will be made unilaterally. If a modification may have a negative impact on the Client, Onesurance will do so by mutual agreement and only after Client's approval.
Definitions
Capitalized terms shall have the following meaning or the meaning as provided elsewhere in this document:
Acceptance:
Customer's final and written approval of (parts of) the Service(s).
Handling time:
The time measured and recorded by Supplier (including Response Time) between:
- The time of reporting the Incident to Supplier and Supplier's notification to Customer that the Incident has been remedied;
- The time at which this is demonstrably reported by Supplier;
- The time the Service is available again.
Backup: a copy of files, data held on a data carrier to restore this information in the event of a system crash, data loss or other calamity.
Availability: time period expressed as a percentage of the total time measured over a full calendar month in which a Service is available under the appropriate conditions.
Call: a message (by phone/e-mail) from a person in Client's organization or a notification from Onesurances monitoring system.
Data Breach: a breach of confidentiality and/or of the integrity and/or of the Availability of Personal Data where unauthorized persons have inadvertently or unauthorizedly gained access to (client) Personal Data This may result from a variety of causes, such as a cyber-attack, human error, technical failure, or technical error. A Data Breach may result in the unauthorized access to, disclosure of, alteration of, or loss of personal data.
Service(s) means all work to be performed by Supplier on behalf of Customer under this Agreement, including all Services, functions and responsibilities not specifically described in this Agreement, but necessary for the proper and/or lawful performance and delivery of the described Services, functions and responsibilities.
Downtime: the period during which the Service is unavailable or unresponsive at all.
Holidays: national Holidays determined by the government and the days on which Supplier has announced to be closed. These days shall not be counted as a Working Day.
Users: the persons employed by or working for the Client and/or using the Acceptance Assistant because they are clients/clients of the Client.
Scheduled Unavailability: the period(s) during which Acceptance Assistant is unavailable due to scheduled and pre-announced (maintenance) work.
Implementation: the whole of actions and measures necessary to put all parts of the Services and supplied software, separately and in mutual coherence, into use in the organization of the Client, in such a way that all Users of the Client can work with it in accordance with the agreed use. If agreed, the Implementation also includes the conversion, the realization of the links necessary for the agreed use and the execution of the acceptance procedure.
Incident: an interruption, deviation, disruption, reduced Availability or reduced speed of an agreed upon service, resource or product.
Office Hours: the period during which Supplier can be reached on the Business Days.
Complaint: (written) expression of dissatisfaction with Supplier's services.
Supplier: Onesurance.
Maintenance Window: time period during which maintenance can be performed on the managed components.
Non-Availability: the periods when Acceptance Assistant is not accessible to the authorized Users in accordance with the agreed functionality as agreed in the service description.
Standard: the percentage of successful incident settlements within the promised times that Acceptance Assistant must meet as a minimum.
Client: the client of Onesurance.
Agreement: the Agreement and attachments
Force Majeure: unforeseen and uncontrollable circumstances beyond a Party's control that may adversely affect performance of the Service. Examples include natural disasters, terrorist activities, power outages, strikes, or other events beyond the reasonable control of that Party.
Parties: Contractor and Supplier jointly referred to as "Parties" and separately referred to as "Party",
Partner: the customer of Supplier, who purchases the Services and/or application from Onesurance .
Priority: the degree of urgency of the Incident, as described in Chapter 5.
Problem: Failure to comply due to an initially unknown cause which may lead to one or more Incidents.
Response Time: the time between receiving a report and when it is acted upon (registration, first contact with Client and start of diagnosis).
Recovery Point Objective (RPO): the maximum period during which data loss is acceptable in the event of a disaster.
Recovery Time Objective (RTO): the maximum time between an Incident and functionality being available again
Request for Change (RFC): a request from Client to change, add or remove a functionality.
AI-as-a-Service: Onesurance s application made available to authorized Users via the Internet.
Security breach: an Incident in which unauthorized persons gain access to data, applications, networks or devices without permission. This can lead to Data Breaches, loss of confidential information or other negative consequences for individuals or organizations.
Support: Supplier's central point of contact for Customer's Users.
Service Level: the level of a partial aspect of the Service(s) to be delivered by the supplier, expressed by means of an indicator.
Service Window: the time frame within which the Service(s) is/are performed.
Fee(s): all Fees agreed upon for the Services.
Working Days: a day falling within Supplier's Office Hours.
Change: a change carried out on (parts of) a Service or infrastructure, with such an impact (potentially) that a careful assessment should precede its introduction.
2. General AI-as-a-Service
Supplier makes its AI-as-a-Service available via the Internet and provides technical maintenance and management of the Services provided. Supplier makes its products available from an EEA-based data center. In order to make use of this, Customer must take care of a:
- Stable Internet connection with speed of at least 5Mbps;
- Chrome browser, equipped with the latest updates;
- Resolution of at least 1600 x 900 combined with a scale of 100%.
The Service is an AI-as-a-Service application and therefore has the following benefits and conditions:
- Client does not have to purchase the software and hardware on which this software is installed, but pays for the use of the AI-as-a-Service;
- Client accesses the AI-as-a-Service via a secure Internet connection;
3. Technical management by Onesurance
Technical maintenance and management will be provided by Supplier. This includes Infrastructure management, Data management, Security management, Compliance & audits and Performance optimizations. Of course, Supplier also takes care of the delivery of new functionalities in the application.
Infrastructure: Managing the hardware infrastructure, such as hosting, servers, and storage, required to support the AI-as-a-Service application.
Data Management: Managing the data stored and processed by the AI-as-a-Service application. This includes implementing, managing and monitoring Backup and Recovery procedures, ensuring data integrity and meeting data protection compliance requirements.
Security Management: Implementing and maintaining security measures to protect the AI-as-a-Service application from threats such as hackers, malware and Data breaches. This includes monitoring security events, performing penetration tests and implementing access control mechanisms.
Service Support: Providing technical support to end users of the application. This includes taking Incidents, handling RFCs and possibly providing paid training.
Compliance and Audits: Compliance with legal and industry compliance requirements such as the AVG, and standards around information and cyber security. In addition, Supplier shall cooperate with annual audits and PEN testing to ensure that the application complies with applicable laws and regulations at all times.
Performance maintenance and optimizations: Managing the systems and identifying opportunities for improving the performance of the AI-as-a-Service application, such as optimizing code and data processing.
Delivery of new functionalities: If new functionalities are needed then Customer can indicate this to Supplier and it will be built by Supplier at an agreed upon cost.
Functional Management Supplier is responsible for the functional management of the Service. This includes Accepting and processing user questions, Maintaining the facility, Performing periodic checks on the operation of the facility, Delivering data and requirements to Customer and collecting user feedback.
Acceptance and processing of user queries: The questions asked by end users must be accepted and processed by the Supplier. If the Customer notices that something is a bug then this can be submitted to Support of Supplier and it will be resolved. New functionalities (RFC) can be submitted via the Customer Success Manager. Generic RFCs are implemented free of charge, for Partner specific requests a Fee is requested which is communicated in advance.
Maintain Setup: The proposal includes an initial setup of the application by Supplier.
Delivery of data and requirements: If Client wants to migrate data, have a new link or request new functionality, then Client is responsible for delivering this information. For links, Customer is responsible for preparing the requirements, collecting the necessary information and credentials, and fully testing and approving the link. Supplier is not responsible for any errors in a prepared and agreed setup.
Collecting User Feedback: Client is responsible for collecting user feedback. With this feedback, Client will improve the user experience by requesting an RFC from Onesurance.
Functional Chain Testing: It is the responsibility of the Client to conduct regular chain tests, testing the functional operation of the application and links. These chain tests serve to ensure the quality of the setup and the integrity of the data. The purpose of this is to ensure that the system functions optimally and meets the specified functional requirements. These requirements can only be checked by the Client itself, as well as the authenticity of the data.
4. Application performance.
To work well with AI-as-a-Service, a fast-working application is very important. Of course, speed depends on several factors, including a well-functioning (Wi-Fi) network. Under optimal conditions, we aim for the following performance, excluding scheduled maintenance and Force Majeure, on a best-effort basis:
Type | Measuring point | Measurement time | Standard performance | Standard |
Availability | Uptime percentage | Monthly | 95% accessibility | 90% |
Speed | Frontend load time | When loading a page | 3 sec | 90% |
Capacity | Number of simultaneous users | During peak load | Max 50 users | 90% |
Recovery time | Time to resolve critical failures | After a critical failure | 48 hours | 90% |
It is the responsibility of the Client to ensure that the environment is regularly cleaned and maintained so that unnecessary data is removed and the system performs optimally without delays due to overload or redundant information that would prevent the above times from being met.
5. Availability of production environment AI-as-a-Service
Supplier commits to an Availability of at least 95% for its AI-as-a-Service, less Planned Unavailability. The performance indicators issued relate to Supplier's service(s) in a production environment and do not apply to Services in an acceptance environment. Availability is calculated per calendar month according to the formula:
Uptime = { ( T - D ) / T } * 100% T: Service Window per month D: Total Unavailability (Downtime) Downtime in a Maintenance Window, is excluded from the calculation. |
Our principles around Availability are:
1. Work that has an impact on the Availability of the AI-as-a-Service will be performed outside Office Hours as much as possible, about this maintenance Supplier will inform Customer in writing at least 7 days in advance. In exceptional situations the Supplier may have to perform these activities within Office Hours, this will only be done in case of high priority and after consultation with Customer.
2. Non-Availability due to the reasons and causes below cannot be attributed to Supplier and is therefore outside the Availability:
a) Maintenance work agreed with Customer in writing during the Maintenance Window
(b) Incidents due to Force Majeure.
6. Availability of acceptance environment AI-as-a-Service
If desired by Customer, Supplier will provide the possibility of setting up an acceptance environment. This will be discussed during the project phase and if necessary set up by Supplier, who will also be responsible for maintaining the environment. Supplier commits to an Availability of the acceptance environment of at least 85% for its AI-as-a-Service, less the Planned Unavailability. The Acceptance Environment Availability is lower than the production environment because test scenarios are regularly rolled out for our Partners, allowing for extensive testing before items go to production. The performance indicators issued relate to Supplier service(s) in an acceptance environment and do not apply to Services in a production environment. Availability is calculated per calendar month according to the formula:
Uptime = { ( T - D ) / T } * 100% T: Service Window per month D: Total Unavailability (Downtime) Downtime in a Maintenance Window, is excluded from the calculation. |
The principles around Availability for the acceptance environment are:
1. The acceptance environment will be updated with the new functionalities after consultation and by arrangement.
2. If an update needs to be implemented earlier then this will be discussed and implemented by mutual agreement at a time when the impact to Client is minimal.
3. Important updates are carried out during the day after the Client has been informed of them in a timely manner and has been able to take measures, if necessary, as a result, the application may be temporarily unavailable.
7. Measuring Availability.
To proactively measure Availability, Supplier uses:
- Monitoring of servers to measure whether they are active;
- Monitoring the AI-as-a-Service for activity and environmental load;
- Number of successful login checks on the AI-as-a-Service;
Login control principles:
- Login control assumes one login attempt per minute within the Service Window;
- Login attempts during the Maintenance Window are ignored.
A printout of non-sensitive information such as Availability in percentage can be provided upon request.
8. Monitoring the environment
Like the infrastructure, our AI-as-a-Service solutions and associated portals are monitored 24x7. If disruptions occur in the underlying infrastructure or on the application, the Supplier receives an automated notification. Supplier attempts to resolve the disruption immediately. Service Window
Supplier guarantees within the Service Window an Availability according to the Standard below.
Description | Availability | Note |
Service Window | 8:30 - 17:30 Monday through Friday | Exclusive Maintenance Window |
Maintenance Window | Announced and planned | If necessary with advance notice |
Standard Availability | 95% | Per month within the Service Window |
The Maintenance Window allows Supplier to perform scheduled maintenance on predetermined time frames.
Description | Availability | Note |
Maintenance Window | Announced and planned | Potential impact on Availability or Performance* |
*Maintenance with impact on Availability will be announced in writing at least 7 Business Days in advance, unless there is a security incident and/or urgent Change. In the latter case, Supplier will contact Customer's contact person here as soon as possible. If it is foreseen that an urgent Change may cause a conflict with regular maintenance in the Maintenance Window, Supplier will first perform the urgent Change and if possible after that the regular maintenance. If it is not possible to perform the regular maintenance, another time will be scheduled for this regular maintenance. The priority is always to implement the urgent Change. In order to guarantee the service it is important to implement relevant updates in a timely manner. Supplier therefore implements the new security updates according to the deadline below.
Rating | Lead time | Explanation |
Not critical | < 3 maanden | A (security) Incident that occurs where there is no business impact |
Medium Priority | < 1 maand | A (security Incident that occurs where the business impact is minimal and there is no risk of data breach. |
High Priority | Per direct, < 72 uur | A (security) Incident that occurs where a business impact is possible. |
Critique | Per direct, < 48 uur | A (security) Incident that occurs where a business impact is significant. |
9. Responsibilities testing after maintenance
Supplier is responsible for the uptime of the application and technology. After maintenance, Supplier will therefore perform a check on the operation of the functionalities. If any Changes are made in the setup of the application, Customer will be notified in advance by email. It is the Supplier's responsibility to perform a functional test after an update to check whether functionality still works as initially intended. Links are not modified without mutual consent (if the operation of the link changes) and are therefore outside the scope for testing after maintenance. Updating the acceptance environment, testing and release to production is always done based on pre-communicated planning from Supplier.
Support services
Support Requests
Supplier provides support on its AI-as-a-Service. For this purpose, Support from Supplier is available to answer and handle service requests (Calls). Service Requests may only be notified by Customer's project support. Telephone accessibility for this support is during Office Hours.
Service Desk service | Days | Period |
Support: +31 6 132 70 144 | Mon to Fri* | 08:30-17:30 a.m. |
*excluding Holidays
Reports that are posted are picked up within Office Hours based on Priority. The Priority is initially specified by Customer, with Supplier having the option to adjust the Priority.
The parties may, at the request of the Client, agree to temporarily deviate from Office Hours and purchase additional Availability, such as during the execution of projects and/or releases.
Scope and types of Calls
The type of Call primarily covered by the SLA and to which the terms of the SLA apply is an Incident. This is an error in the software, link or data which disrupts the normal operation of the Service or produces unwanted results. There are three categories in this:
- Incidents, fixing them;
- Privacy and security Incidents and malfunctions;
- Correction requests, correcting damaged data or links where the cause is Supplier.
Secondary Calls are not covered by the SLA terms but will be handled by Supplier. This includes:
- Restore requests, restoring Backups.
- Questions, answering questions from functional management;
- Consulting, hiring for training;
- Request for Changes (RFCs), requests for software modifications;
- Any other questions and/or requests that are not directly related to the AI-as-a-Service.
Client shall indicate the type of Call when registering a Call. It is up to Supplier to check this and change it if necessary. Secondary Calls are normally paid assignments, apart from RFCs that can be built generically by Supplier. The request to restore a Backup where the cause of the need for a Backup does not lie with Supplier is also a paid assignment.
12. Complaints and communication matrix
If there are Service Complaints, they can be passed on to the assigned Customer Success Manager of Supplier. Support records the Complaint and assigns it to a handler. Customer will be kept informed of the progress. After Acceptance of the complaint report by Customer, the report is considered resolved and the report is closed. If there is no resolution and/or if the Complaint is sensitive it can be discussed in a higher echelon. An escalation may be reported to Supplier's Customer Success Manager at the time a Report is not satisfactorily addressed/resolved. If there is reason to escalate to another level it can be done according to the communication model below.
13. Incident Management
The goal of incident management is to ensure that the Acceptance Assistant is operational again as soon as possible. Incident management is not about fixing the cause.
- Incidents are handled based on Priority and turnaround time. Incidents with a higher Priority always have priority;
- An Incident is considered resolved if Supplier realizes a (temporary) solution that restores the agreed operation.
The order of handling Incidents reported to Supplier shall be determined by Supplier subject to the prioritization described in this section. It may happen that Supplier notices an Incident earlier than Customer. If it is a Priority 1 Incident, Supplier shall notify its Partners immediately via written notification. If it persists for more than 4 hours, an update will be provided via email, including a report on the cause and resolution.
Client can assign an urgency level when reporting an Incident. When reporting an urgency "prio 1" you must make this known to Support by telephone before sending a written report toonesurance This is to ensure a "warm" transfer, so that the urgency is immediately known within Supplier. The Standards regarding urgency are included below:
Description | Urgency | Example |
Prio 1 | Critique | The Services are no longer usable and a workaround is not possible. |
Prio 2 | High | Normal execution of part of the Service is not possible, impact is significant. |
Prio 3 | Medium | The Services do not work completely but there is no further business impact. |
Prio 4 | Low | An Incident that occurs where there is no business impact. |
The notifier can provide the Priority of the Incident, it is checked by Support based on the above conditions and conformed or modified.
Response & Handling Time
For a Priority 1 Incident, Supplier will provide a structural solution or realize a workaround acceptable to Customer. This means that Supplier will keep to its best efforts obligation until the functionality is normally available again, or the urgency is scaled down to prio 2 or 3.
For prio 2 and 3 Supplier can decide to handle further handling of a Call according to planning. This is reported in the handling of the Call by means of a schedule. This is for example the case with bug fixes in application and/or interfaces.
Supplier applies the following criteria and lead times with respect to the resolution of Incidents. As soon as it is clear that the resolution of an Incident cannot be achieved within the agreed resolution time, Supplier, in consultation with the notifier, takes the decision to initiate the escalation procedure.
Priority | Response time | Handling time | Standard |
Prio 1: critical (during Office Hours) | < 60 minuten | < 48 uur | 95% |
Prio 2: high (during Office hours) | < 4 uur | < 72 uur | 95% |
Prio 3: medium (during Office Hours) | < 1 Werkdag | < 20 Werkdagen* | 95% |
* Prio 3 bugs are generally resolved faster, but when development work is required it is scheduled and delivered on the next sprint. In doing so, the latest lead time is 20 Working Days.
For items lower than a prio 3, no Handling Time applies as these are not blocking issues. As a rule, these items go along with the development speed of Priority 3 Incidents.
15. Change Management
Changes within the Acceptance Assistant environment are organized into 3 categories:
1. Changes to optimize Acceptance Assistant on a functional and/or technical level is initiated by Supplier. These are Modifications with the purpose of adding functionalities to the environment and/or eliminating Problems;
2. Calls classified as RFC to make a modification at the request of Client, this can be to add or modify a functionality, but also to perform a restore;
3. Standard Changes, these are modifications that do not impact existing functionality.
Similarly, Modifications may only be submitted by Customer's project supervision. If costs are involved in the modification, Supplier will only implement the Modification after written approval from Customer. Submission of Changes should be done through the Service Desk as described in section '4.1 Support Requests'. The change process after development is included below in section '5.3 Software release'.
16. Software release
Supplier uses continuous integration, so there is a possibility to transfer delivered changes, which have a higher urgency, directly to the production environment. Less urgent changes that are delivered will be delivered in accordance with agreements made in advance. When delivering a release, Supplier releases release documentation up to a maximum of 1 week after the release. This documentation describes what changes, relevant to the Customer, are included in the next release. After the software release, Supplier performs testing, but the Partner is also expected to test on the Acceptance environment if present, and after the release on the Production environment. It is possible to request new functionality or a software modification from Supplier. This can be done by submitting a Request for Change (RFC) to the Customer Success Manager. The Customer Success Manager also provides feedback on the request whether it has been approved, or rejected.
17. Legal requirements
Supplier is bound by laws and regulations. We adapt our software to this in a timely manner, so that Customer can also comply with it in a timely manner. These legal Changes are delivered by a software release in the AI-as-a-Service.
18. Problem management
The goal of problem management is to reduce the likelihood and impact of Incidents by identifying actual and potential causes of Incidents, and managing workarounds and known errors.
Problem identification is initiated from the following situations:
1. All reports related to Incidents that cannot be resolved immediately, but for which a workaround is available, are qualified as a Problem;
2. Incidents that occur more frequently but cannot be resolved immediately and for which no workaround is available are qualified as a Problem;
3. Supplier periodically analyzes the number of notifications coming in, both from Client and internal monitoring. By classifying and grouping the notifications, the AI-as-a-Service recognizes trends. These trends may indicate structural Problems/uncertainties for Client and/or in the technology. Based on these trends, Supplier investigates the cause and comes up with a structural solution. The solution will reappear in a subsequent release;
4. Supplier is responsible for realizing a workaround, Customer is responsible for testing and Accepting the workaround.
19. Security and hosting
Security Supplier makes every effort to keep its Services secure through security measures. Supplier does this from infrastructure to application. In the event of a Security breach, Supplier reserves the right to immediately disable the AI-as-a-Service to limit any claim . Supplier makes every effort to identify and resolve the cause. Supplier logs a prio critical Incident for this and also handles it in accordance with this process.
Security testing If Customer wishes to perform security testing on the AI-as-a-Service, Customer must request permission from Supplier. Supplier asks this in order to prevent unexplained notifications from following at its premises, which could lead them to take measures detrimental to the continuity of one or more customers. The test can be scheduled in consultation. Supplier will in all cases cooperate with such requests. The costs for security testing will be borne by Customer. The summary of this will be shared and is also available by email upon request. In addition, there is an active 4-eye principle on all code going to the production environment.
Data processing Supplier, as a processor, never processes data for purposes other than those agreed upon and for which a legal basis exists. Furthermore, data is never stored by Supplier at locations outside the European Union. This applies to both hosting and disaster recovery locations.
The Service are hosted at Microsoft's Azure Cloud Services. These are designated as sub-processors by Supplier in the processor agreement. For more information on Microsofts Azure certifications, see https://learn.microsoft.com/en-us/azure/compliance/.
20. Redundancy and Backup
For Backups, Onesurance uses the Backup policy as provided by Microsoft Azure. More information about this policy can be found at: https://learn.microsoft.com/nl-nl/sql/relational-databases/Back-up-restore/backup-overview-sql-server?view=sql-server-ver16. Supplier is responsible for creating database Backups and testing for integrity. Backups of the primary data center are performed according to the following schedule:
Type of Backup | Surroundings | Type | Frequency | Retention period |
Database | Production | Full | Daily | 1 week |
Production | Differential | Every 24 hours | 4 weeks | |
Production | Transactional | Every 10 min. | 3 months |
The Backup is then handled in the following manner:
Service | Service Level |
Archiving location | Based on Zone Redundant Storage |
Backup window | Out of Office Hours |
Redundancy | No processed data is stored on the Onesurance side. In the event of a critical situation, the hosting for the API will be re-established and deployed, or a recent Backup of this environment restored. |
RPO | 8 working hours |
RTO | 24 hours |
Location | Address |
MS West Europe | Cultuurweg 11, 1775 RA Middenmeer, The Netherlands |
To ensure that the environment is recoverable, Supplier periodically (1x per year) performs a full recovery recovery action. To ensure that the environment is functionally usable after the recovery action, Supplier involves one or more Partners in this. A report is also made of this action, making it demonstrable for all Supplier's Partners and end customers and audit that we have performed this action. This will be discussed further during tactical consultations.
21. Technical architecture
AI-as-a-Service environments are deployed with a combination of a number of Azure tools:
- Azure DevOps (for orchestrating the process from code to application in the cloud);
- Azure Machine Learning (for storing the model);
- Azure App Service (for hosting the API) and Terraform (for defining the Azure infrastructure in code templates). The code can be found in Azure DevOps.
In order to securely test modifications to the model and API, there are two endpoints (URLs) for the API that can be used. This is a functionality of Azure App Service called "deployment slots." This makes it easy to run two versions of the model side by side in the cloud.
22. Monitoring, detection
Supplier has active monitoring and detection on both servers and software. This means that possible improper login attempts by malicious parties are actively monitored. In case of irregularities, automated alerts are sent to Support by return. These alerts are always considered a Prio 1 Incident, which means that appropriate action can be taken immediately.
23. Information Security
Information security is an important component within Supplier. Because sensitive information is stored and processed, we have a number of important processes in place to ensure the integrity of the data.
24. Information security structure
Supplier is actively engaged in information security and its control. For both application maintenance and operations, there are a number of people responsible for overseeing and monitoring this. The Data Protection Officer role is an executive and internal role. The Data Protection Officer ensures proper Implementation and monitoring of applicable laws and regulations and resulting obligations. The Data Protection Officer advises the management of Onesurance and writes information security policies with them. Within Onesurance , this role also includes monitoring the implementation of the policy in the organization and execution.
25. Data incidents
When a Data Breach is suspected, the Data Protection Officer is called in immediately. The Data Protection Officer investigates the reported Incident together with the Heads of Engineering and Machine Learning and, within 24 hours of suspicion of a Data Breach, reports back to the Client via Support whether a Data Breach has occurred. If so, an Incident Report (see Section 7.3) is prepared and, if necessary, relevant agencies are notified. A comprehensive report will be made and Supplier will conduct in-depth investigation to determine the cause, identify areas for improvement and create an action plan describing how similar situations will be prevented in the future. Implementation of this action plan will commence immediately after the Data Breach has been sealed.
26. Incident Report
When a Data Breach occurs, an incident report is prepared and shared with the Incident reporter and all stakeholders involved in the Incident. An incident report consists of the reporting of the Problem, its cause, impact and resolution. The Problem is remedied as soon as possible and the recipients of the incident report are kept informed. The Data Protection Officer oversees proper handling, resolution of the Incident and aftercare. In the aftercare, Supplier will investigate ways to prevent a similar situation from occurring again and will report this to in the Incident Report.
27. OTAP Street
If agreed with Customer, Supplier will use OTAP methodology for software development. In this way a clear distinction is made in the different environments. The development team works in the development environment, Supplier consultants test in the test environment, the Partner tests in the acceptance environment and the Users work in the production environment. Split environments and databases are used so that no data Incident can occur due to mixing of data across environments.
©2025 Onesurance B.V.
©2025 Onesurance B.V.
©2025 Onesurance B.V.