Service Level Objectives (SLOs)
Scope and introduction
This document outlines the service level objectives (SLOs) we (Intigriti) strive to meet or exceed when providing our standard service offering. Our service level objectives cover platform availability, onboarding, triage and bounty payments. We will strive to meet these objectives under normal operating conditions but deviations may occur, for example during periods of high demand. For custom triage requirements, identified as such during the discovery phase, other service level objectives may apply. If you (our client) believe this is applicable to your service, please reach out to your customer success manager for more information.
These service level objectives are published for transparency and operational alignment. They are internal target objectives and do not constitute a binding commitment of Intigriti. If we materially fail to reach our service level objectives, clients may require us to determine and provide insight in a formal action plan. We will then transparently report and act with the sole aim to avoid repeated failure in the future. The service level objectives as detailed herein are not part of a contractual commitment and will not trigger contractual remedies or compensation of damages, unless to the extent expressly so agreed in writing in such contract. In case of a contradiction between these service levels and any service levels included in a written contract between Intigriti and the client, the service levels as included in the contract will prevail.
We may amend these service level objectives upon 2 weeks prior notice on our platform.
Terminology
Capitalized terms used in this document will have the following meaning:
| Term | Meaning |
|---|---|
| Available and Availability | Means the effective and qualitative availability of the Platform online. |
| Downtime | Means a period during which the Platform is not Available. |
| Emergency Maintenance | Means any maintenance of the Platform that is required to be done without undue delay, for example to anticipate on an imminent security threat or to address or prevent significant problems with the operation of the Platform. |
| Incident | Means unplanned Downtime or any event which is not part of the standard operation of the Platform and which causes, or may cause, an interruption or a reduction of the quality of the Platform service. |
| Material Downtime | Means Downtime exceeding twenty (20) consecutive minutes. |
| Planned Maintenance | Means any maintenance of the Platform which is planned and notified minimally two (2) weeks in advance on status.intigriti.com. |
| Platform | Means Intigriti’s crowdsourced security solution accessible via app.intigriti.com. |
| Platform Availability | Means the period of time or % of time during which the Platform is considered Available. |
| Platform Operating Time | Means the period during which Availability of the Platform is provided, as specified in part 3 (Platform availability) of this document. |
| Response Time | Means the time between the moment a client makes a Support Request, and the moment Intigriti provides a first answer, which can consist of an acknowledgement of receipt, ask for additional information, or confirmation that the Support Request is complete. |
| Resolution Initiation Time | Means the time between our receipt of a complete Support Request and the moment Intigriti actively initiates the Resolution of the relevant Incident. |
| Resolved or Resolution | Means the restoration of Platform functionality to normal operation after the occurrence of an Incident. Resolution can be provided as a permanent fix, via a patch and/or as a temporary workaround. |
| Service Window | Monday – Friday, 08.00 – 18.00 CET Excluding Belgian public holidays. |
| Support Desk | Means the application/ functionality where Incidents must be reported, as specified in part 4 (Platform support) of this document. |
| Support Request | Means the Client’s notification of an Incident to the Intigriti Support Desk. A Support Request is considered complete when the Intigriti Support Contact has received all information needed to reproduce the Incident |
| Target Resolution Time | Means the time between our receipt of a complete Support Request and the moment the Incident is Resolved. |
| Target Tolerance Percentage | Means the percentage of Support Requests that will be tolerated to be handled outside of the support levels set forth in this document. |
Platform availability
We aim to provide our clients and researchers with consistent and reliable access to our platform, to maintain user trust and operational continuity. Our service level objectives for Platform availability define the expected uptime and performance thresholds, outlining the commitments we make to minimize downtime and disruptions.
We strive to provide Platform Availability for all users across supported regions during Platform Operating Time, based on the following objectives:
| Parameter | Target value |
|---|---|
| Platform Availability | 99% during Platform Operating Time |
| Platform Operating Time | Monday – Sunday, 7/7 days 24/24h |
Platform Availability is calculated on a monthly basis, as follows:
| Term | Meaning |
|---|---|
| POT | The total Platform Operating Time (in hours/ minutes) for the calculation period. |
| POT Downtime | The total period of Downtime (in hours/ minutes) during the calculation period, minus Downtime for Excused Events. |
| Excused Events | (i) Any acts, events or circumstances that are beyond our reasonable control such as but not limited to (natural) disaster, government instruction, extreme weather conditions, war, hostilities, pandemic or embargo (force majeure events); (ii) acts of third parties which we could not reasonably prevent; (iii) Planned Maintenance announced in accordance with these SLOs; (iv) Emergency Maintenance required to safeguard stability or security; (v) failure of the client (or its users) to use the Platform in accordance with the agreement, documentation, instructions or with due care; (vi) issues caused by the client (or its users) own network, internet provider, firewall, VPN, devices, or other systems under the client’s control; (vii) service limitations caused by our security measures, including rate limiting, DoS/DDoS mitigation, abuse detection, or blocking of suspicious or malicious traffic. |
Planned Maintenance which is expected to cause Downtime will, where reasonably possible, be performed outside of the Service Window. If Material Downtime is expected for reason of Planned Maintenance or Emergency Maintenance, this will be communicated on status.intigriti.com; detailing its expected impact. We will always reasonably strive to maximize availability and minimize Downtime, also during periods of maintenance.
Intigriti will report on Platform Availability and will provide communications related to Platform Availability, Downtime and maintenance on status.intigriti.com.
Platform SLOs may vary during major releases or infrastructure upgrades.
Platform support
Users are requested to report Incidents to our support team without undue delay, to enable us to maintain a high level of operational quality.
Platform support is available during the Service Window and can be contacted via the support chat functionality in our platform (the “Support Desk”).
Platform support is available in the English language.
When reporting an Incident to the Support Desk the following information must minimally be provided: A short description of the Incident and how it occurred:
In which situations the Incident occurs;
Steps to reproduce;
Timestamp of occurrence;
The type of device and browser used when the Incident occurred;
The effects of the Incident;
Any other relevant information reasonably requested by Intigriti.
Service levels related to Resolution of an Incident start counting as of the moment all information is available as necessary to reproduce the Incident.
Intigriti will strive to adhere to the following support levels for Incident Support, calculated during the Service Window:
| Priority | Response Time | Resolution Initiation Time* | Target Resolution Time |
|---|---|---|---|
| 1 | 10 minutes | 10 minutes | 4 hours |
| 2 | 1 hour | 30 minutes | 1 day |
| 3 | 4 hours | 1 hour | 5 days |
| 4 | Best effort | Best effort | Best effort |
Intigriti will strive to adhere to the aforementioned response and resolution targets in 95% of cases (support level compliance of 95%).
Support level compliance is calculated on a monthly basis as follows:
Priority is defined on the basis of a combination of the urgency and the impact of the Incident, as follows:
| Impact | High Urgency | Medium Urgency | Low Urgency |
|---|---|---|---|
| Platform is not Available | One or more core functionalities of the Platform cannot be performed | Subordinate functionalities of the Platform cannot be performed | |
| High Impact (Affects all users) | Priority 1 | Priority 1 | Priority 2 |
| Medium Impact (Affects 50% or more of users) | Priority 1 | Priority 2 | Priority 3 |
| Low Impact (Affects a single user / small subset of users (<10%)) | Priority 2 | Priority 3 | Priority 4 |
Onboarding
We strive to provide a structured and efficient onboarding experience, tailored to the client’s subscription tier and scope as agreed in discovery phase.
During onboarding, we strive to meet the objectives detailed herein, of which the feasibility highly depends on the collaboration of our clients. We expect that our clients allocate sufficient time and competent personnel, to ensure efficiency and smooth onboarding in line with agreed timelines.
Shortly upon signature of the Agreement, and at latest within two (2) weeks, our Customer Success team will invite the client to participate in a remote intake meeting. The parties will mutually agree upon a date for the first kick-off call, therein determining the timeline for onboarding.
The ideal timeline looks as follows:
Kick-off meeting: Within five (5) working days of contract signature.
Onboarding plan delivery: Within five (5) working days post kick-off.
Platform access setup: Within three (3) working days of receiving required client inputs.
Training & familiarization: Scheduled within five (5) working days of platform access.
Completion of onboarding: Within four (4) weeks from kick-off call.
Launch of the first Program: Strongly dependent on the client’s input.
Timelines may be adjusted for bulk onboarding, custom configurations, or dependencies on third-party systems.
Triage
We strive to provide timely and consistent handling of vulnerability submissions made through our platform. Our triage and validation process consists of the following phases:
| Phase | Scope | Description |
|---|---|---|
| Submission availability | All severities | As a client, you can access all submissions made under your program in real-time, in accordance with our service level objectives for Platform Availability. This applies both for validated and unvalidated submissions. |
| Initial assessment | Critical and exceptional vulnerabilities | Our triage team will perform a preliminary analysis to confirm or amend the severity of the reported critical and exception vulnerabilities, based on the information submitted by the researcher. Moreover, the triage team will prioritize the submission based on the validated severity. The initial assessment phase is completed once the severity is either confirmed or corrected. |
| (First) validation | All severities | As part of the validation phase, our triage team will perform a more in-depth analysis of the submission, to verify if: (i) the content of the submission is clear and understandable; (ii) the reported submission is in scope of the program; (iii) the submission is unique or concerns a duplicate of an earlier submission; and (iv) the vulnerability is reproducible (if applicable). The (first) validation phase is completed once the triage team undertakes either of the following actions: (i) Reject submission (in case of duplicate or out of scope); (ii) Request more information from the researcher; (iii) Validate submission (move to ‘pending’) and notify client. |
| Follow-up validation | All severities – only if additional information is requested under first validation phase. | During follow-up validation, our triage team will: (i) process additional information provided by the researcher; (ii) further communicate with the researcher, as necessary to obtain sufficient information to validate the submission; (iii) complete the verifications of the first validation phase. Calculation of the service level objective for follow-up validation starts as from the moment we receive additional information from the researcher. If the researcher again has provided insufficient information to validate the submission, our triage team will ask for additional information and as of that moment the calculation of the service level objective will stop. Each time new information is received from the researcher, the clock is reset, and a new service level calculation starts. The follow-up validation phase is completed once the triage team undertakes either of the following actions: (i) Reject submission (in case of duplicate, out of scope or if the researcher remains unresponsive for more than one week); Validate submission (move to ‘pending’) and notify client. |
| Client validation | All severities – only validated submissions | Upon receipt of notification for a validated submission, clients will review and confirm the submission, in accordance with the conditions/ requirements of the program. To ensure continued researcher engagement and motivation, researchers must receive timely acknowledgement of and compensation for their efforts; and therefore we request that clients do so within the time objectives in the below table. Following a prior warning, submissions that remain unconfirmed for more than 2 months can be confirmed by us, if they meet the program requirements and bounties will be paid accordingly. Exceptions may be agreed on between the client and the customer success team, provided that adequate motivation is provided and an adequate timeline agreed upon in writing. |
| Bounty payment | As applicable | If and as applicable according the program’s bounty table, we will pay a bounty to the researcher and deduct the corresponding amount from your bounty budget. |
Upon receipt of a vulnerability submission on your program, we strive to meet or exceed the below service-level objectives for triage, calculated during Service Window. A grace period will apply during program launch and launch of new program scope.
| Phase | Triage objective for priority submissions | Triage objective for other submissions |
|---|---|---|
| Severity: Critical, Exceptional | Severity: Low, Medium, High | |
| Submission availability | Real-time during Platform Operating Time | Real-time during Platform Operating Time |
| Initial assessment | Up to 1 business day | N/A |
| First validation | Up to 1 business day | Up to 2 business days |
| Follow-up validation | Up to 1 business day | Up to 2 business days |
| Client validation | Without undue delay Up to one (1) month from Submission notification | Without undue delay Up to one (1) month from Submission notification |
| Bounty payment (if applicable) | Up to one (1) month from Client validation* | Up to one (1) month from Client validation* |
*Provided that Intigriti has received all required information from the researcher.
We will strive to adhere to the triage objectives in 95% of cases, calculated over a period of 2 weeks (triage objective compliance of 95%).
Triage objective compliance is calculated on a 2 week basis as follows:
